prow: investifgate not exposing any job configuration to the test container

[stevekuznetsov]

Follow-up to #7594

We should try to understand the current set of uses that jobs have for the Prow environment variables like $JOB_SPEC and determine if all of those use cases are solved by the pod utilities. If they are not, we should write more utilities to handle those cases. Test jobs should not really need infra level config exposed them.

/area prow
/kind enhancement
/assign

[BenTheElder]

Our jobs definitely consume:

• PULL_REFS
• BUILD_NUMBER (they shouldn't but I guarantee something still does...)
• BUILD_ID

Other than JOB_SPEC specifically, the prow env seem like useful things to expose. One use case for example is integrating with coveralls.io.
For JOB_SPEC OTOH we're not consuming this at the moment, and I'd rather see the PJ logged to cold storage.

[stevekuznetsov]

Right but why are they?

• $PULL_REFS should be consumed by clonerefs and not be important to jobs. Jobs should not muck with git state themselves if they're using the pod utilities.
• $BUILD_NUMBER should be consumed by the GCS upload utilities, why would the job care?
• $BUILD_ID same?

[BenTheElder]

PULL_REFS is read by other tools to produce metadata about the job run, which avoids them using git in any fashion... coveralls wants to know the refs for example.
BUILD_ID / BUILD_NUMBER are used as unique IDs, see for example: #7682

[BenTheElder]

I don't think the podutils should handle these cases. And by exposing these we prevent jobs trying to produce them on their own.
I also consume the ORG / REPO related env for bazel caching to key it, see: https://github.com/kubernetes/test-infra/blob/master/images/bootstrap/create_bazel_cache_rcs.sh

[stevekuznetsov]

Those are perfect use-cases, thanks :) The point of this is just to investigate how we are using them and if there is room for another util or not.

[stevekuznetsov]

As explained by Ben, we should keep exposing this info to tests.

/close