-
Notifications
You must be signed in to change notification settings - Fork 91
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: Port CI to GitHub Actions #780
Conversation
For some reason, macOS is failing now, where it already passed in 312845f. Since it complains that
|
d4ef88e
to
a779cc3
Compare
fb1df50
to
92401eb
Compare
with: | ||
python-version: ${{ matrix.python-version }} | ||
|
||
- name: Install Dependencies |
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.
Why not move this after the actions/cache
step so it is also cached?
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.
Btw protip: you can skip entire steps based on the action/cache
step's output: getsentry/sentry-docs#2231
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.
We're not caching toolchain installations, only cargo's own cache and the target folder. These are the expensive operations that take time. All the rest is usually so fast that caching doesn't really matter and I opted to reduce caches to the absolute minimum.
FWIW, you can see that release builds don't have caches at all, to ensure we're never working off a poisoned cache.
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.
FWIW, you can see that release builds don't have caches at all, to ensure we're never working off a poisoned cache.
I don't think poitioned caches are a significant thread but even if they were, we can simply make the caching step conditional on this not being a release branch and speed up PR builds?
git config --global user.name "$(git log -1 --pretty=format:%an $GITHUB_SHA)" | ||
git config --global user.email "$(git log -1 --pretty=format:%ae $GITHUB_SHA)" | ||
git clone https://getsentry-bot:[email protected]/getsentry/sentry-data-schemas |
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 this part can/should be replaced with actions/checkout
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.
Sounds good, I'll consider that in a follow-up PR. These jobs were just moved, so I would like to not touch them.
My plan is to make this a reusable action that we can use for all sorts of cross-committing activities we do in the organization.
This is ready now. Will disable AppVeyor and update status checks just before merging and then push the changelog to trigger the final build. |
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.
lgtm!
- release/** | ||
|
||
jobs: | ||
linux: |
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.
You could use a matrix here, but tbh what you have is probably more clear despite some duplication
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.
Good point. I had a matrix at first, but ended up choosing this for the cleaner config. As soon as craft
supports GitHub artifacts, the biggest chunk of duplication (zeus uploads) will be gone and this will be neat and clean. Would propose to revisit once we can move off Zeus.
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.
Do we really want to stop using the makefile entirely in CI? That creates a split between local dev and it.
ZEUS_API_TOKEN: ${{ secrets.ZEUS_API_TOKEN }} | ||
ZEUS_HOOK_BASE: ${{ secrets.ZEUS_HOOK_BASE }} | ||
run: | | ||
npm install -D @zeus-ci/cli |
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.
out of curiosity, what was wrong with install -g
and running the binary directly?
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.
Good point, I can try that. Originally, I used just npx
, and then noticed that it is reinstalling on every invocation. On Azure Pipelines, one cannot run global installations, but that may work on GitHub actions.
on_success: | ||
- zeus job update --status=passed || echo "%$APPVEYOR_REPO_BRANCH%" | findstr /V "release/">nul | ||
|
||
on_failure: |
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.
on_failure does not seem to be ported, is there no equivalent on gha?
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.
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.
Also, we no longer need this, as we do not depend on Zeus for status checks. It is only an artifact storage, so it does not matter whether we report failures.
|
||
- name: Deploy | ||
if: github.ref == 'refs/heads/master' | ||
uses: peaceiris/actions-gh-pages@v3 |
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.
this has come up before but do we have a general policy wrt third-party github actions? since github tags are mutable as opposed to most package registries, and this has access to a token
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.
Deferring to the policy-makers here. So far, there has been no push-back.
Note that this was not changed from master, just moved.
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.
Maybe @billyvg has insights?
@@ -2,5 +2,12 @@ | |||
members = ["relay", "relay-*", "tools/*"] | |||
default-members = ["relay"] | |||
|
|||
[profile.dev] |
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.
This seems like counterintuitive behavior. Do we want to start doing this across the org?
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 we should do this only where it shows significant benefits. I can imagine doing this in symbolicator, although there stack traces are actually useful for debugging in contrast to Relay. Repositories like symbolic
or even smaller crates build fast enough so that such a hack is not necessary.
For the curious: This cuts build times in half, and reduces the size of the target folder by 45%.
Here are two test releases with craft:
|
This will require getsentry/craft#124 for successful publishing with craft. Once we've released a patch release of craft, we need to bump the minimum craft requirement in |
Moves all CI jobs from Travis and AppVeyor to GitHub Actions. This comes with a few changes in the build pipeline:
Due to the wheel change, this will require a changelog entry.