3

GitLab supports a variety of Push Options. Is there any way to check, in the web user interface or otherwise, what push options were used in a pipeline or job? In particular, what ci.variable push options are associated with the job or pipeline?

One workaround is to run env with every job, but it seems like this information might already be available in the user interface.

sytech
  • 29,298
  • 3
  • 45
  • 86
davidvandebunte
  • 1,286
  • 18
  • 25

1 Answers1

4

Git hooks

The only definitive way to know exactly what git push options were used is in a pre-receive or post-receive git hook or looking at server logs. This is only possible on a self-managed GitLab instance.

In these hooks, the GIT_PUSH_OPTION_COUNT tells you how many push options were used. The variables GIT_PUSH_OPTION_<i> contain each option. So you could configure a hook that inspects these variables to know which options were used.

Getting pipeline variables using the API

If you just need to know what variables were used for creating the pipeline and don't care about the source, that can be done with the pipelines API.

This will include variables for the pipeline added by git push options, but does not distinguish between variables added by git push options or other sources and won't contain variables added at the job level or dynamically.

curl --header "PRIVATE-TOKEN: <your_access_token>" \
"https://gitlab.example.com/api/v4/projects/1/pipelines/46/variables"

Also keep in mind the caveat that it's possible for variables to change mid-pipeline. So, this may not be adequate if you must be 100% assured of the environment for every job at every stage in the pipeline.

Runtime introspection likely insufficient for differentiation

If the goal is to determine, specifically, which variables were added by git push options (and not any other sources), doing this at runtime may be difficult to do with 100% certainty.

By the time a pipeline has been evaluated and the job is running, environment variable configurations could have changed and you can't be 100% certain of the source of a variable. You may be able to guess in some circumstances by introspecting the environment, pipeline configuration file, project and group CI/CD configurations, etc. But there will likely be gaps due to permission and other issues.

Some obstacles that will be difficult or impossible to overcome to determine variable source from introspection:

  1. You may not have permission to inspect ancestor group or instance level variables
  2. If you use self-hosted runners, variables can be configured on the runners
  3. Variables can come from the image: used.
  4. Variables can be set dynamically by triggers or artifacts
  5. Variable configurations may change after the pipeline/job are started

In other words, you may not know if a new variable comes from a git push option or a change in any of these other things you can't inspect at runtime.

One workaround is to run env with every job

That would give you 100% certainty of the environment for each job. But still you would not know which ones came from the push options, as opposed to other sources, as mentioned above.

You could also artifact the environment and retrieve that artifact programmatically, but you may risk placing sensitive information in your artifacts, so that's probably not a good idea on its own, unless you're very careful to exclude them.

You could enable debug logging but that also has security risks.

sytech
  • 29,298
  • 3
  • 45
  • 86