ci: Build workhorse binaries and upload/download as generic package
All threads resolved!
Compare changes
+ 3
− 2
@@ -204,11 +204,12 @@ setup-test-env:
This MR does two things:
build-components
job that runs automatically for all GitLab.com gitlab-org/gitlab
scheduled pipelines, for any master
commit that touches the workhorse/
folder, and is manual for GitLab.com's gitlab-org
's MRs.
tmp/tests/gitlab-workhorse
).scripts/setup-test-env
, so that the GitLab Workhorse binaries are built.setup-test-env
job to:
build-components
.tmp/tests/gitlab-workhorse
), preventing the building of the binaries when scripts/setup-test-env
is run later on.scripts/setup-test-env
Notes:
TestEnv
didn't have to be touched at all, so this is really an optimization that sits on top of what we have today (i.e. caching of GitLab Workhorse binaries).workhorse
tree SHA (i.e. git rev-parse HEAD:workhorse
).workhorse
shouldn't change too often, most of the MRs should be able to take advantage of the pre-built package, which would be built every two hours.TestEnv
directly, so that local GDK instances, and GitPod instances (not sure about that) would benefit from it as well (though, different architectures should be taken in account, see gitlab-development-kit#1391).scripts/setup-test-env
With package | Duration |
---|---|
No | 92s, 84s, 82s |
Yes | 42s, 44s, 46s |
It looks like we could already save 42 seconds on average for the setup-test-env
job.
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #351035 (closed).