-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: Start using github actions for CI #235
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice! do we care about other OSs for symbolicator? Might be good to use a matrix for that maybe? https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix
The current travis config only tests on linux, so I did the same here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it, thank you so much for getting this started!
My only issue with this is that it diverges from the Makefile
, which is our canonical "source of truth" for such commands. Is it possible to invoke make *
commands, particularly the ones we run in Travis at the moment?
After that, if caches turn out to be stable, I'd be more than happy to remove the Travis and AppVeyor builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, meant to request changes.
On an unrelated note, would you mind updating the PR title? The type
in the beginning should match one of the types declared here: https://develop.sentry.dev/code-review/#type. Thanks!
By using the actions-rs/cargo "action" thingy we get the integration which comments in the PR on the right locations for lints etc. If we want that functionality for the make target we'd have to write our own action I think. I'd rather be able to use the community maintained actions I think. I imagined that we'd add another workflow with (some of) the makefile things in it before actually ditching travis. But my intention here wasn't actually to try and ditch travis, just try out the actions features for a while in parallel to see if it's worth investing in migrating and how we would like migration to look. |
Deciding how to integrate the makefile functionality is more interesting. I'm thinking adding another workflow which invokes the makefile e2e tests is straight forward, though that already duplicates the rust tests. The overlapping linting etc is more interesting. |
It would be nice if there was a filter you could apply to rust's and pytest's output to turn it into action-compatible errors and lints so we could run everything from the makefile. Maybe that's too crazy. |
This now does everything that the travis run does, but faster. The clippy and cargofmt runs are not using the makefile so we get annotations from actions-rs. The "Rust Check" stop is entirely new and gives faster build feedback with annotations. Bot unittest and integration tests have to do the same cargo build which should take about the same time. However because both test suites take >30s it's worth to duplicate this. |
This is only the basic rust actions, not all things done by travis currently are covered yet.
Using artifacts rather than caches since here we're explicitly including the app build itself.
We don't (yet) build a binary.
The makefile also didn't do this.
We don't actually want to upload docs for normal PRs
run: pip install --upgrade black flake8 | ||
|
||
- name: Run Black | ||
run: black --check tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: should we use this directly instead of makefile for symbolic as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're going with explicit commands now, I would say yes. The makefile becomes an interface for the developer, and CI has it's own (equivalent or equal) commands.
pytest.skip("No AWS credentials") | ||
msg = "No AWS credentials" | ||
if pytestconfig.getoption("ci"): | ||
pytest.fail(msg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory this kind of stuff could be monitored by measuring coverage on the testsuite itself. Then you can find tests that are improperly skipped or not discovered at all for whatever reason.
In practice it's much harder to set up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that could work if you have a 100% test coverage enforced. But anything less and it probably doesn't. I like one global that you can use to potentially skip things on local workstations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean testing coverage of the code in tests/
, not the code that is being tested. Surely all tests are running in CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
craft.yml
still requires the following artifacts:
symbolicator-Linux-x86_64
symbolicator-Linux-x86_64-debug.zip
Unfortunately, merging like this will break releases. The artifacts were built by the release: linux x86_64
Travis job. You can either remove the craft requirement, or add the release build back.
Nothing currently produces these binaries, this is currently broken.
Deleted these two from Producing binaries opens up so many questions for me that I really would rather not mix that up into this PR. Apologies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleted these two from .craft.yml as I think things were broken since they were added.
I'm not sure what makes you say that. Both the build and the craft configuration look fine to me. I remember testing this when I added it. But it's up to you, we can bring this back later.
I was mistaken that this wasn't currently done. Let's keep it.
Apparently we now have CI independently from the Makefile.
Note to self:
My cache does not support git dependencies yet, but it looks like it would be a small win here |
Ok, I read the existing travis.ymy and makefile badly again. Re-added this now. Ready to merge again I think. I assume once this is merged with admin rights the requirement for the travis checks will disappear again? |
Updated branch protection rules on GitHub. |
Almost comprehensive replacement of CI in github actions:
TODO:
#skip-changelog