Skip to content
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

Merged
merged 39 commits into from
Sep 21, 2020
Merged

ci: Port CI to GitHub Actions #780

merged 39 commits into from
Sep 21, 2020

Conversation

jan-auer
Copy link
Member

@jan-auer jan-auer commented Sep 18, 2020

Moves all CI jobs from Travis and AppVeyor to GitHub Actions. This comes with a few changes in the build pipeline:

  • Python linting and formatting is checked again
  • The macOS wheel now requires 10.15.0 since this is the minimum version offered by GitHub
  • Integration tests no longer run haproxy or gobetween. They can be added as service if they provide any value.

Due to the wheel change, this will require a changelog entry.

@jan-auer jan-auer requested a review from a team September 18, 2020 07:47
@jan-auer jan-auer marked this pull request as draft September 18, 2020 07:47
.github/workflows/ci.yml Outdated Show resolved Hide resolved
@jan-auer
Copy link
Member Author

For some reason, macOS is failing now, where it already passed in 312845f. Since it complains that serde_derive is missing, I'm assuming that caches are somehow broken.

error[E0463]: can't find crate for `serde_derive` which `serde` depends on
##[error] --> relay-redis/src/config.rs:1:5
  |
1 | use serde::{Deserialize, Serialize};
  |     ^^^^^ can't find crate

.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
with:
python-version: ${{ matrix.python-version }}

- name: Install Dependencies
Copy link
Member

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?

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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?

.github/workflows/ci.yml Show resolved Hide resolved
.github/workflows/deploy.yml Show resolved Hide resolved
.github/workflows/deploy.yml Show resolved Hide resolved
Comment on lines +81 to +83
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
Copy link
Member

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

Copy link
Member Author

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.

@jan-auer jan-auer marked this pull request as ready for review September 18, 2020 20:42
@jan-auer
Copy link
Member Author

jan-auer commented Sep 18, 2020

This is ready now. Will disable AppVeyor and update status checks just before merging and then push the changelog to trigger the final build.

Copy link
Member

@billyvg billyvg left a 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:
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

@untitaker untitaker left a 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
Copy link
Member

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?

Copy link
Member Author

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:
Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member Author

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]
Copy link
Member

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?

Copy link
Member Author

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%.

@jan-auer
Copy link
Member Author

jan-auer commented Sep 21, 2020

@jan-auer
Copy link
Member Author

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 craft.yml and then this can be merged.

@jan-auer jan-auer merged commit e5c85a6 into master Sep 21, 2020
@jan-auer jan-auer deleted the build/remove-appveyor branch September 21, 2020 08:35
@jan-auer jan-auer mentioned this pull request Sep 21, 2020
jan-auer added a commit that referenced this pull request Sep 21, 2020
* master:
  feat: Scrubbing of UTF-16 strings in minidumps (#742)
  meta: Update CI badges (#782)
  fix(pii): Fix issue where `$span` would not be recognized in Advanced Data Scrubbing (#781)
  ci: Port CI to GitHub Actions (#780)
  fix(setup): Log when reporting to Sentry is disabled (#779)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants