needs to be expanded to mention that the variables are passed to dependent jobs, assuming that is deliberate behaviour that users can rely on.
Proposal
Expand the text to say something along the lines of "any variables set are also automatically accessible to any latest jobs in the pipeline that depend on the job with the artifact, as per the normal rules for when artifacts are passed to a job".
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
I'd like to know how using artifacts::reports::dotenv is any different than simply creating an artifact file and using '. artifact/myenv.env' in your before_script definition?
My guess is that it is automatically added into the environment of the job and I don't have to do the '. artifact/myenv.env' portion?
I guess thats handy but unless someone is familiar with that behavior they may not easily understand. looking at a before_script that explicitly dots in the file is much more universally understood.
Help me understand if I'm missing some added benefit.
@mattpascoe
these vars are added to the pipeline scope and thus are available automatically for all subsequent jobs.
i was under the impression that these vars are made available to the job before its created and thus are eligible for substitution in places that wont work when the var is set when the job runs, eg. in the environment:
what i specifically want to test is, if these are available for the rules: b/c those really are eval'ed when the pipeline starts, if i start to understand gitlab things...
Yes, I can't imagine this wording being any more confusing:
The dotenv report collects a set of environment variables as artifacts.
The collected variables are registered as runtime-created variables of the job...
This is open to so much interpretation as to be almost flat-out incorrect. How about:
The dotenv report exposes the specified .env file as runtime environment variables in subsequent jobs, as well as captures the file as a downloadable artifact on the current job.
The current wording makes it seem like the artifact exposes the variables on the current job and not other jobs.
Based on the documentation, it is not clear to me if you can modify a dotenv created variable in subsequent jobs. If you can, does the dotenv file need to be the same or different?