Backport of go: don't download pipeline modules when caching build modules into release/1.18.x #29238
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This PR is auto-generated from #29224 to be assessed for backporting due to the inclusion of the label backport/1.18.x.
The below text is copied from the body of the original PR.
Description
Various different CI jobs need Go modules in order to build or test
Vault. To speed this up in CI we cache them in Github Actions.
The caching requires downloading all modules first in order to upload
them to the actions cache, which is performed by calling the
go-mod-download
Make target. This target will iterate over thedirectory tree and download Go modules in all directories that include
a
go.mod
file.There are two small problems with this approach that we resolved with
this PR:
go-mod-download
target would download modules for allgo.mod
's present in the directory tree, regardless of whether or notthey are required to build or test Vault. Only downloading those
required results in slightly smaller caches.
tools/pipeline
is intentionally a separate Go module so as to notrequire its modules in order to build Vault, however, our
go-mod-download
downloading all modules requires the workflowenvironment to include auth credentials for internal modules. If a
community contributed PRs modifies a
go.mod
, which in turn requiresa new cache, the PR will always fail because it cannot download
modules that require secrets.
Now we avoid installing our
tools/pipeline
modules when generating ourmodule cache which should allow community contributed PRs to execute
build and Go tests, while skipping enos workflows which already required
secrets and were thus skipped.
TODO only if you're a HashiCorp employee
backport/
label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x
, but older release branches will bebackport/ent/x.x.x+ent
.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.
Overview of commits