-
Notifications
You must be signed in to change notification settings - Fork 312
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 migration to Github Actions, part 2 #5974
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #5974 +/- ##
==========================================
- Coverage 37.89% 37.79% -0.11%
==========================================
Files 371 371
Lines 20661 20661
==========================================
- Hits 7830 7808 -22
- Misses 12057 12070 +13
- Partials 774 783 +9 ☔ View full report in Codecov by Sentry. |
UPDATE: After internal discussion, it was decided to trigger all workflows except release (linters, unit tests, E2E tests, all platforms build) on every single PR. |
612afff
to
172cfe7
Compare
172cfe7
to
7e6f53e
Compare
7e6f53e
to
db11f14
Compare
Continuation of the CI migration to GitHub Actions started in Part 1.
This PR includes the following changes:
Packages build workflow added
This workflow utilizes strategy matrix to run multiple build operations in parallel - currently, 4 (chosen semi-randomly) platform build simultaneously. With this step, the original
go run mage.go -v GenerateEnvFile
operation had to be restored because the package build operations depend heavily on the internal CI framework, and changing that is not in the scope of this task.Single CI workflow is broken down into 3 separate pipelines: unit tests and linters, E2E, and build packages.
The first version of the new workflow was triggered on every PR. With the new build packages job added it had to be changed, and having multiple pipelines that depend on each other is the most suitable approach. The proposed update makes the following CI job chain:
v*
tags (release)Release packages workflow will be added as the last step after the "Build packages" job completion.
This CI pipeline logic is not final and is open for discussion.
NOTE: The internal CI framework is still responsible for most of the triggering logic based on the env variables, so pipeline separation has a more cosmetic effect - we should see different jobs fired in different conditions instead of one huge workflow for every single push with the hidden skip/run switches.