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

RFC: Migrate CI to GitHub Actions? #618

Closed
whitequark opened this issue May 21, 2020 · 8 comments
Closed

RFC: Migrate CI to GitHub Actions? #618

whitequark opened this issue May 21, 2020 · 8 comments
Milestone

Comments

@whitequark
Copy link
Contributor

whitequark commented May 21, 2020

I've set up GitHub Actions for a different project and was pleasantly surprised by how well they work. This has some significant potential benefits for us, including:

  • Unifying the build configuration for Windows, Linux and macOS (strictly speaking we could do this on Travis or AppVeyor just as well);
  • Uploading artifacts for each build on all platforms, not just on Windows, simplifying the life of macOS and to lesser degree Linux users;
  • Significantly faster builds, since all of our submodules already live on GitHub and checkouts are a significant contributor to AppVeyor build times;
  • Better build sequencing, such as not building Snap packages if tests fail on Windows (which may indicate a Windows-specific problem, but quite often points to a generic problem that goes undetected on Linux build bots);

Any opinions or objections?

The main direct benefit is having artifact uploads, which Travis just doesn't provide at all. A potential alternative would be to use AppVeyor for everything, but I found GitHub Actions a lot less frustrating to work with than AppVeyor overall.

cc @ppd since this will impact Snap builds

@ghost
Copy link

ghost commented May 21, 2020

FTR, GitHub Actions artifacts (as I know) could not be downloaded by not logged users (e.g. there are no anonymous downloading for GitHub Actions artifacts).

I may be wrong.

@whitequark
Copy link
Contributor Author

whitequark commented May 21, 2020

You are correct (I think they do it to avoid excessive bandwidth costs). This isn't a huge problem though since we can publish a rolling "nightly" pre-release, like wasmtime does. So the artifacts would be published as assets like here.

@ppd
Copy link
Member

ppd commented May 21, 2020

There's an upstream action for snapcraft: https://github.com/snapcore/action-build and it seems like arm64 and amd64 are both supported.

So this seems like a good idea, snap-wise.

@phkahler
Copy link
Member

phkahler commented Jun 9, 2020

@whitequark you had mentioned that the current build are debug anyway, so not suitable for general use. Would this change include producing release builds?

Either way, if it makes life easier I say do it.

@whitequark
Copy link
Contributor Author

whitequark commented Jun 9, 2020

Would this change include producing release builds?

We could far more easily set it up so that e.g. after debug builds succeed and go through testing, there is another round of release builds that are uploaded for general use. You can kind of do this with Travis/Appveyor but it's a huge pain with those.

@ppd
Copy link
Member

ppd commented Jul 2, 2020

I must correct my statement regarding arm64 support: the only way to build on arm64 seems to self-hosted runners. Github-hosted runners are only amd64 as far as I can see (https://github.community/t/does-github-actions-support-multiple-os-architectures/16526).

@phkahler
Copy link
Member

Closing because it looks like we're going with Travis for now.

@ppd
Copy link
Member

ppd commented Oct 17, 2020

We can come back to this if necessary. Travis has its own problems, but it's a) there and b) has brittle arm64 support as a USP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants