We have a multiple pipeline yml files created by different developers and included all of them in the .gitlab-ci.yml.
To restrict my pipeline to run everytime, I created a rule to run only if that value is passed.
So now, my pipeline will run only if that variable value is passed.
So far good, but when I trigger the pipeline to run and pass the variable value, along with my pipeline, other pipelines also running.
How to restrict other jobs to not trigger and trigger only my jobs without touching their yml files?
Would it be possible for you to post a simplified version of your
.gitlab-ci.yml file with your rules?
I asked a very generic question, what is the need of sample yml files?
How to restrict all other default jobs to run and run only the new job created wihtout touching the rules of existing jobs?
It was just the
.gitlab-ci.yml file I was thinking about. It’s not completely clear to me exactly how your
rules work, or why all the other pipelines run when your variable is set.
It is quite common on this forum for people to ask questions about their
.gitlab-ci.yml file, and many people will include the file, or part of it, often with many details removed, just to demonstrate the issue that they are asking about. For example, this question that I asked a couple of years ago contains a very small part of a much larger CI config.
Don’t have a specific pipeline to show the example.
Not required also, the requirement is simple.
Let me phrase it again.
I have multiple jobs in the pipeline.
If I trigger the pipeline, all will run.
I have added a new job and added it to the pipeline at the end of list.
I have skipped my job to run by setting a condition to check for a variable value.
So, if the pipeline it triggered, all jobs will run and mine will be skipped as I am expecting the variable value, say testdeploy = aws.
If I pass the value, all jobs will run along with mine at the end.
How to add any setting in my job, so that, when I ran pipeline, all jobs will be skipped and only mine will run.
This is completely generic, not specific to my job.
An example configuration file allows us to copy it into our own projects to better understand the described workflow, and make suggestions - sometimes as diff towards the config file. Please help us in helping you