This is a feature request coming from a previously closed issue. There has been requests from multiple customers to implement it. This feature would allow tags within the gitlab-ci.yml file to be able to utilize variables, which they currently are not able to.
In this closed issue, a user points out that utilizing a variable like $CI_BUILD_REF_NAME does not work and actually hangs in the tags: section.
The issue has been closed but multiple paying customers in the last ~5 months have asked for it to be looked at as a viable feature again.
Proposal
The proposal from the previous issue included these possible solutions --
When evaluating a .gitlab-ci.yml file to schedule a job, first perform variable substitution prior to the logic used for selecting a runner.
Additionally consider implementing regex-style variable manipulation as proposed in gitlab-foss#24044 (closed). These two improvements combined would be especially powerful.
Permissions and Security
Documentation
Testing
What does success look like, and how can we measure that?
I merge into different branches to move the ci/cd pipeline into different environments. I would like to tag a runner with the branch name and be able to use the CI_COMMIT_REF_SLUG to select the runner.
@thaoyeager happy new year, picking up this thread for my customer. I'd like to arrange a call w/ the customer and you / your team next week to detail their use case and identify workarounds (if any), but can we sync up first so I can give you the backstory on the notes from my meeting? I'll reach out on Slack also. Thanks!
@bcupini Hello! I'm guessing since we did not connect on Slack that a call with the customer has not yet been scheduled. When ready, please coordinate with @jyavorska who is helping out as interim PM for Verify:CI.
@bcupini I've marked this as a duplicate of gitlab-runner#1809 (closed) for which @DarrenEastman is the PM, and is the more broad issue that is a single case of. He would be the right PM to chat with.
This appears to be a duplicate of gitlab-runner#1809 (closed) which is seeking a general solution for allowing variable substitution within other variables. Please let me know if I've missed something here, though.
I believe gitlab-runner#1809 (closed) should remain a separate issue or updated to explicitly state that job tags should be made dynamic:
Currently a tag is just a constant string. You cannot use any variables in a tag. But gitlab-runner#1809 (closed) is about using nested variables (A -> B -> C).
Correct me if I'm wrong, but variable substitution in gitlab-runner#1809 (closed) is done after runner instance has already been selected. And dynamic tag should be used before that to select an appropriate runner instance.
@vitaly.ogoltsov We have updated the proposed implementation plan in gitlab-runner#1809 (closed) to handle expansion of known variables in GitLab Rails. However, in reading this issue, I don't think that gitlab-runner#1809 (closed) will address this use case of tags within the gitlab-ci.yml file being able to utilize variables.
We also need this variable runner tag feature or "dynamic tags", in order to standardize and use centralized templates for pipelines that run on different servers depending on the project or deployment environment.
This way we would be able to handle hundreds of different project repositories that reference and include the same pipeline template stored on a shared repository, running on the proper gitlab runner for each project.
I'm trying to wrap my head arround this solution, and I don't see how I can use this to select/target specific runner based on tags:
Could you please explain it a bit more?
I'm creating on-demand runners on google cloud. I want to achieve that single runner runs single pipeline, so If i have two pipelines in one project, I want to have two runners running each of the pipelines.
Does your solution applies to this kind of scenario?
since #15356 (closed) is scheduled for 13.0 and would be much, much more useful if parallel/matrix jobs could be assigned to different runners via variables, could we get this scheduled for 13.0 or 13.1 as well?
I agree that having dynamic tags as suggested above would allow for more standardized CI templates to be created and used across many different projects. For example, the following could be a desired state (using an example configuration entry that would be inherited from):
Assuming here I have $SITE defined to a specific environment, and I have a $SITE-ansible runner designated for that environment. My goal here would be to let a tag for a runner be chosen based on the variable I pass to the pipeline. The reason this is extremely valuable is it allows a single project or CI file to define pipelines for multiple sites or environments while minimizing repeated code.
Current workarounds have been to either create multiple projects to logically separate deployments or create duplicate job definitions with different hardcoded tags. This leaves quite a bit of CI code behind to maintain and update as new features are developed and code is refactored.
Recently, I leveraged the Dynamic child pipelines feature to achieve the same goal. While this involves spawning a child pipeline instead of having the single "base" pipeline choose dynamic tags, this solution does have the same functionality.
In the base .gitlab-ci.yml file (example below), the first job utilizes a Python script to generate a complete dynamic gitlab-ci file from a template (also below) which is then exported as a job artifact. The Python script leverages the jinja2 library to fill the template out with the appropriate variable(s). This artifact is then passed to the next job which leverages the "dynamic" child pipeline feature to create the desired pipeline.
Relevant subsection of .gitlab-ci-template.yml.j2 below. After generate_ci_template.py fills this Jinja template out, it is saved as .gitlab-ci-complete.yml and set as an artifact.
I know this doesn't solve the need for dynamic tags, but I was able to use it to gain the same level of abstraction while being able to transition to dynamic tags when available.
@thaoyeager As the Runner team needs to also work on gitlab-runner#1809 (closed), I propose that we also take on the work to deliver a solution for this issue as well. If you agree, then starting next week, we will start refining both issues and update the issue descriptions with high level implementation plans and timelines.
Not sure if this has been mentioned earlier but doing this would allow reuse of the same job across environments with this type of functionality instead of re-declaring the same job for every environment even if the definition is the same.
Now that we have the parallelmatrix option. It would be even more powerful if we could use variables tags so we can target different runners for different jobs produced by the matrix values.
(Exactly what was mentioned in #247493 (closed))
I am interested in a realted feature. Our use case is to make sure that certain pipelines always run on the same servers again as we want make use of local caching (without using the limited and slow cache feature from the runner). I think there are plenty of different use cases which require that the tag and therefore runner distribution can happen dynamically.
But instead of using only variables, we actually would like to be able to apply rules as well. I opened #258601 with this request.
We'd also love support for this feature. We're currently trying to lock down runner execution per environment, and not being able to dynamically assign tags based on environment/branch via $CI_COMMIT_REF_NAME or similar is currently blocking/breaking our workflow. We can probably move to a non-environment specific runner setup but this prevents us from reaching our security and compliance objectives for our customers.
This is definitely something we miss - we use tagging to target dockerized gitlab-runners for deployment onto staging and production docker swarms. The tags correspond to different branches anyway, and there is so much simplification that can be done to gitlab-ci files when this feature is released.
@nagyv-gitlab This seems like a pretty popular request, based on the and customer requests. Is this a feature that you would consider pulling into future releases?
@dcoy Sorry the runner team doesn't currently have the cycles to prioritize this effort on our near-term roadmap.
@thaoyeager fyi - on the runner side we are close to wrapping up the other work related to variables, gitlab-runner#1809 (closed) but we no longer have the cycles to pick this one up.
@DarrenEastman@thaoyeager Just wanted to follow up to see if there has been a change in prioritization or idea of when it might be able to be placed on the roadmap?
Would love to see this get implemented, will make our life easier dealing with deployments on multiple servers on a load balancer reusing the same job within a matrix
@DarrenEastman@thaoyeager A large Premium customer https://gitlab.my.salesforce.com/00161000003bZRr is very interested in seeing this feature. Their use case: they have two cloud providers and currently are using two sets of jobs in the same stage, but they want to have only one job, and, based on what the cloud provider is, switch the tag appropriately so the job is picked up by the right runner for the right cloud provider. We're happy to schedule a call to discuss more in-depth if it would be helpful.
Just adding visibility to this issue. Similar feature request been popping up here for last 4 years, yet nothing is implemented to fulfil such a common scenario.