You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be beneficial to enable pipelines to modify the environment.environment like it's already supported for environment.contents.packages via needs.packages pipeline field.
Note: this is different from what the pipeline environment field provides, because it instead allows injecting environment into the specific pipeline (step) only.
Being consistent with regard to the interface and considering the scope of injection, it could be exposed via a needs.environment field.
Use cases
An example that would benefit from this is the go/covdata pipeline that requires the GOCOVERDIR environment variable to be set when running the coverage instrumented-Go binary.
In example, because the tests that run the instrumented Go binary require that environment variable in order to allow the go runtime to write coverage data files, the final go/covdata is a no-op without the correct environment set globally for all the steps.
Once implemented the feature, the go/covdata could be modified as follows:
and a package with binary instrumented for generating coverage data, could be as easy as specifying:
at build time: the compiler option.
at test time: adding at the end the coverage data collection pipeline, transparently.
# crane.yaml
...
subpackages:
- name: ${{package.name}}-coverpipeline:
- uses: go/buildwith:
packages: ./cmd/craneextra-args: -coverldflags: -buildid= -X github.com/google/go-containerregistry/cmd/crane/cmd.Version=${{package.version}} -X github.com/google/go-containerregistry/pkg/v1/remote/transport.Version=${{package.version}}output: cranetest:
environment:
contents:
packages:
- jq# The following can be removed thanks to go/covdata needs.environment['GOCOVERDIR']=/home/build#environment:# GOCOVERDIR: /home/buildpipeline:
- name: Verify Crane installationruns: | crane version || exit 1 crane --help
- name: Fetch and verify manifestruns: | crane manifest chainguard/static | jq '.schemaVersion' | grep '2' || exit 1
- name: List tags for a public imageruns: | crane ls chainguard/static | grep -E 'latest|v[0-9]+.[0-9]+.[0-9]+' || exit 1
- name: Validate image existenceruns: | crane digest chainguard/static:latest && echo "Image exists" || exit 1
- name: Pull and save an image locallyruns: | crane pull chainguard/static:latest static_latest.tar || exit 1 [ -f static_latest.tar ] || exit 1
- uses: go/covdata
The text was updated successfully, but these errors were encountered:
maxgio92
changed the title
Feature request: allow pipelines to modify environment.environment
Feature: allow pipelines to modify environment.environment
Feb 27, 2025
Uh oh!
There was an error while loading. Please reload this page.
Feature
It would be beneficial to enable pipelines to modify the
environment.environment
like it's already supported forenvironment.contents.packages
vianeeds.packages
pipeline field.Note: this is different from what the pipeline
environment
field provides, because it instead allows injecting environment into the specific pipeline (step) only.Being consistent with regard to the interface and considering the scope of injection, it could be exposed via a
needs.environment
field.Use cases
An example that would benefit from this is the
go/covdata
pipeline that requires theGOCOVERDIR
environment variable to be set when running the coverage instrumented-Go binary.In example, because the tests that run the instrumented Go binary require that environment variable in order to allow the go runtime to write coverage data files, the final go/covdata is a no-op without the correct environment set globally for all the steps.
Once implemented the feature, the
go/covdata
could be modified as follows:and a package with binary instrumented for generating coverage data, could be as easy as specifying:
The text was updated successfully, but these errors were encountered: