Skip to content

Feature: allow pipelines to modify environment.environment #1823

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

Open
maxgio92 opened this issue Feb 27, 2025 · 0 comments · May be fixed by #1827
Open

Feature: allow pipelines to modify environment.environment #1823

maxgio92 opened this issue Feb 27, 2025 · 0 comments · May be fixed by #1827

Comments

@maxgio92
Copy link
Contributor

maxgio92 commented Feb 27, 2025

Feature

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:

diff --git a/pkg/build/pipelines/go/covdata.yaml b/pkg/build/pipelines/go/covdata.yaml
index b90b539..737856e 100644
--- a/pkg/build/pipelines/go/covdata.yaml
+++ b/pkg/build/pipelines/go/covdata.yaml
@@ -5,6 +5,8 @@ needs:
   packages:
     - ${{inputs.package}}
     - busybox
+  environment:
+    GOCOVERDIR: /home/build

 inputs:
   package:

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}}-cover
    pipeline:
      - uses: go/build
        with:
          packages: ./cmd/crane
          extra-args: -cover
          ldflags: -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: crane
    test:
      environment:
        contents:
          packages:
            - jq
        # The following can be removed thanks to go/covdata needs.environment['GOCOVERDIR']=/home/build
        #environment:
        #  GOCOVERDIR: /home/build
      pipeline:
        - name: Verify Crane installation
          runs: |
            crane version || exit 1
            crane --help
        - name: Fetch and verify manifest
          runs: |
            crane manifest chainguard/static | jq '.schemaVersion' | grep '2' || exit 1
        - name: List tags for a public image
          runs: |
            crane ls chainguard/static | grep -E 'latest|v[0-9]+.[0-9]+.[0-9]+' || exit 1
        - name: Validate image existence
          runs: |
            crane digest chainguard/static:latest && echo "Image exists" || exit 1
        - name: Pull and save an image locally
          runs: |
            crane pull chainguard/static:latest static_latest.tar || exit 1
            [ -f static_latest.tar ] || exit 1
        - uses: go/covdata
@maxgio92 maxgio92 changed the title Feature request: allow pipelines to modify environment.environment Feature: allow pipelines to modify environment.environment Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant