mystiq/rageshake
Archived
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
No description
This repository has been archived on 2022-08-18. You can view files and clone it, but cannot push or open issues or pull requests.
107 commits 13 branches 8 tags 6.5 MiB
Go 93.3%
Shell 4.4%
HCL 1.2%
Dockerfile 1.1%
Find a file
Michael Kaye 78060556a2 Serve a tarball containing the contents of a given directory. 
This will make it easier to get all logs for a given bug; preventing users
needing to run scripts to download all files.

 - we cannot make the link exist in the directory listing as there are scripts
   that automate downloads which would pick this up.

 - Unsure if "?format=tar.gz" is the right option to enable this; I couldn't think
   of something easy to do but hard to not get picked up by existing automation, and
   wouldn't conflict with existing filenames.
2022-02-09 16:06:44 +00:00
.buildkite Add support for creating GitLab issues (#37) 2021-08-10 18:04:58 +01:00
.github Merge pull request #47 from matrix-org/sandhose/docker-improvements 2022-01-21 15:21:52 +01:00
changelog.d 1.5 2022-02-08 15:03:54 +00:00
docs genericWebhookURLs as a list rather than a single endpoint. 2022-02-01 13:26:29 +00:00
hooks clean up lint scripts 2020-06-04 12:53:08 +01:00
scripts clean up lint scripts 2020-06-04 12:53:08 +01:00
.gitignore Rename sample config file 2017-04-12 15:27:50 +01:00
CHANGES.md 1.5 2022-02-08 15:03:54 +00:00
CONTRIBUTING.rst move CI to buildkite 2020-06-04 13:08:27 +01:00
docker-bake.hcl Build and push a debug variant of the image 2022-01-21 11:23:54 +01:00
Dockerfile Set the workdir back to / in Docker image 2022-01-21 11:33:35 +01:00
go.mod Bump gopkg.in/yaml.v2 from 2.2.2 to 2.2.8 (#43) 2022-01-20 14:34:53 +00:00
go.sum Bump gopkg.in/yaml.v2 from 2.2.2 to 2.2.8 (#43) 2022-01-20 14:34:53 +00:00
LICENSE Add readme, contributing, license 2017-04-04 16:20:50 +01:00
logserver.go Serve a tarball containing the contents of a given directory. 2022-02-09 16:06:44 +00:00
main.go genericWebhookURLs as a list rather than a single endpoint. 2022-02-01 13:26:29 +00:00
rageshake.sample.yaml genericWebhookURLs as a list rather than a single endpoint. 2022-02-01 13:26:29 +00:00
README.md Initial attempt at a generic webhook for reports. 2022-01-31 15:25:17 +00:00
RELEASING.md fix thinkos in RELEASING.md 2020-06-05 09:33:50 +01:00
slack.go fix lint 2020-06-04 12:52:39 +01:00
submit.go Allow upload of files with a .json postfix. 2022-02-08 10:58:21 +00:00
submit_test.go Update test to look for file to not gain an additional .gz extension. 2022-01-18 17:28:01 +00:00
towncrier.toml 1.1 2020-06-04 13:15:38 +01:00

README.md

rageshake Build status

Web service which collects and serves bug reports.

rageshake requires Go version 1.16 or later.

To run it, do:

go build
./bin/rageshake

Optional parameters:

  • -config <path>: The path to a YAML config file; see rageshake.sample.yaml for more information.
  • -listen <address>: TCP network address to listen for HTTP requests on. Example: :9110.

HTTP endpoints

The following HTTP endpoints are exposed:

GET /api/listing/

Serves submitted bug reports. Protected by basic HTTP auth using the username/password provided in the environment. A browsable list, collated by report submission date and time.

POST /api/submit

Submission endpoint: this is where applications should send their reports.

The body of the request should be a multipart form-data submission, with the following form field names. (For backwards compatibility, it can also be a JSON object, but multipart is preferred as it allows more efficient transfer of the logs.)

  • text: A textual description of the problem. Included in the details.log.gz file.

  • user_agent: Application user-agent. Included in the details.log.gz file.

  • app: Identifier for the application (eg 'riot-web'). Should correspond to a mapping configured in the configuration file for github issue reporting to work.

  • version: Application version. Included in the details.log.gz file.

  • label: Label to attach to the github issue, and include in the details file.

    If using the JSON upload encoding, this should be encoded as a labels field, whose value should be a list of strings.

  • log: a log file, with lines separated by newline characters. Multiple log files can be included by including several log parts.

    If the log is uploaded with a filename name.ext, where name contains only alphanumerics, ., - or _, and ext is one of log or txt, then the file saved to disk is based on that. Otherwise, a suitable name is constructed.

    If using the JSON upload encoding, the request object should instead include a single logs field, which is an array of objects with the following fields:

    • id: textual identifier for the logs. Used as the filename, as above.
    • lines: log data. Newlines should be encoded as \n, as normal in JSON).

    A summary of the current log file formats that are uploaded for log and compressed-log is available.

  • compressed-log: a gzipped logfile. Decompressed and then treated the same as log.

    Compressed logs are not supported for the JSON upload encoding.

    A summary of the current log file formats that are uploaded for log and compressed-log is available.

  • file: an arbitrary file to attach to the report. Saved as-is to disk, and a link is added to the github issue. The filename must be in the format name.ext, where name contains only alphanumerics, - or _, and ext is one of jpg, png, or txt.

    Not supported for the JSON upload encoding.

  • Any other form field names are interpreted as arbitrary name/value strings to include in the details.log.gz file.

    If using the JSON upload encoding, this additional metadata should insted be encoded as a data field, whose value should be a JSON map. (Note that the values must be strings; numbers, objects and arrays will be rejected.)

The response (if successful) will be a JSON object with the following fields:

  • report_url: A URL where the user can track their bug report. Omitted if issue submission was disabled.

Notifications

You can get notifications when a new rageshake arrives on the server.

Currently this tool supports pushing notifications as GitHub issues in a repo, through a Slack webhook or by email, cf sample config file for how to configure them.

Generic Webhook Notifications

You can receive a webhook notifications when a new rageshake arrives on the server.

These requests contain all the parsed metadata, and links to the uploaded files, and any github/gitlab issues created.

Details on the request and expected response are available.