Add test for symbolicator pipeline

[emmatyping]

Fixes #1888

This integration test:

uploads a symbol file, which indicates where to find the symbols for the minidump
uploads a sample minidump, which creates an event we can check for

This test is based on the test here: https://github.com/getsentry/sentry/blob/28f4f36b4adc3d39ea80f2f1864cff8e311b6af3/tests/symbolicator/test_minidump_full.py#L72

[chadwhitacre]

Passing case. 💃

Let's see it catch a failure! 😁

[BYK]

Observation: I don't recall why I opted for using bash for these tests (probably for something quick and dirty) but at this point, it feels to me that the tests should be a bit more organized and manageable? Maybe using something like Playwright?

[emmatyping]

@BYK eventually I'd like to rewrite the installer in Python and make it so we can use pytest and all the creature comforts that come from that (probably use playwright in tests as well!). But that is a much larger project 😅

[emmatyping]

Here is a sample of a failure: https://github.com/getsentry/self-hosted/actions/runs/3952966281/jobs/6768689917#step:5:6808

Symbol upload will fail of course, so we fail at the sentry-cli point.

EDIT: failing commit now reverted

[BYK]

@BYK eventually I'd like to rewrite the installer in Python and make it so we can use pytest and all the creature comforts that come from that (probably use playwright in tests as well!). But that is a much larger project 😅

This is kind of orthogonal to what I'm suggesting though. There's no reason for integration tests to be in the same language or environment with the installer (maybe it was my faulty brain which fell into this misconseption in the first place, don't really remember). We can right now at this moment, start creating Playwright tests and start benefitting from them which would cut through most of this crazy bash/curl/jq dance with CSRF tokens etc. It would:

• Cover more surface area
• Be easier to understand and maintain
• Have videos of the failures if we wanted to
• Have screenshot tests if we wanted to

Regarding rewriting the installer in Python (or any other language tbh), I'd suggest finding ways of getting rid of it completely (such as by adopting Ansible, Helm charts, or whatever). It would be a challenge to use Python unless the installer gets compiled into a self-contained binary for each system by using something like PyOxidizer

[chadwhitacre]

Also benefiting from #1762: 😁

self-hosted-1-symbolicator-1                               "/bin/bash /docker-e…"   symbolicator                               exited (137)        

[chadwhitacre]

I'm open to Playwright, def separate from installer lang.

[emmatyping]

We can right now at this moment, start creating Playwright tests and start benefitting from them which would cut through most of this crazy bash/curl/jq dance with CSRF tokens etc.

This is true. I am hesitant to start on this since we are near the end of the quarter and I don't want the project delayed much more, but maybe when I add the snuba tests I will add them as playwright tests.

Regarding rewriting the installer in Python (or any other language tbh), I'd suggest finding ways of getting rid of it completely (such as by adopting Ansible, Helm charts, or whatever). It would be a challenge to use Python unless the installer gets compiled into a self-contained binary for each system by using something like PyOxidizer

The idea with that was to make the installer run entirely in docker except for a minimal kickoff script. I agree Ansible might be better, but I'm unsure if making that a dependency is acceptable for our users (right now we only require GNU core utils and docker).