I'm trying to set up a manual job to deploy in production and I'd like to understand the 2nd rule :
deploy_prod:
stage: deploy_prod
rules:
- if: $CI_PIPELINE_SOURCE == 'web'
when: manual
- if: $CI_PIPELINE_SOURCE == 'push' && $CI_COMMIT_BRANCH == 'master'
when: manual
script: echo 1
the first rule allows me to deploy in production by click run pipeline on branch master, which will create a "blocked" pipeline requiring me to click the play button to run.
Is it possible to have that "blocked" pipeline created without having me to click run pipeline (I mean in the list of pipeline, I still want to need to click the play button to run it but that's one less step)
Concerning the second rule, I understand that if I remove when: manual any push (commit, merged branch) to master would trigger the job immediately, so what should be the behaviour when using when: manual ?
Thanks in advance for your help
To have the first rule run automatically without having to manually start it, you can either change when: manual to when: always and it will always run, or you can remove the first rule altogether. This works since you don't have a default rule set (ie, an "else" clause). The way your rules are right now, every pipeline source except for web and push will run automatically, so removing either of the rules will mean they job always runs automatically no matter the source. However, if you don't want the job to run for triggers, schedules, or merge_requests, but want web to run automatically, you must use when: always.
For your second rule, it might be best to clarify what you're asking in a separate question, but really the behavior is up to you.
Related
I have following workflow rules defined:
workflow:
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
changes:
- "**/test.txt"
To summarize I want this work follow to be triggered when both below conditions are met:
There are changes to any of the file in repository with name test.txt
The changes are pushed to master i.e. a merge request is approved.
However, this workflow never gets triggered, even after changes to test.txt are pushed to master or a branch containing those changes is merged.
What might be wrong here?
How can I make to be continuous jobs interruptible?
And by the way, why isn't it the default behavior ?
How can I make to be continuous jobs interruptible?
The jobs can be made interruptible simply by overriding the job(s).
For example, here is how to make one single job (mvn-build) interruptible:
mvn-build:
interruptible: true
And here is how to make all Maven template jobs interruptible (using the base job .mvn-base):
.mvn-base:
interruptible: true
Why isn't it the default to be continuous behavior?
If two branches are merged at the same time, the first resulting pipeline will be cancelled. If the second one has failing tests you won't know which merge was the root cause. This will require some digging to know where the error lies.
Our opinion is that developer's time is more valuable than GitLab CI's so we prefer let him do the extra work by default.
I am currently trying to implement a pipeline using Gitlab ci. I defined my pipeline in a gitlab-ci.yml file to run my jobs. I am working on pipeline where jobs are triggered by opened merge request. more specifically , non WIP and draft merge request. One of the most important condition is also that I want the job to be triggered and running when merge request changes state from WIP/draft to "ready".
Below is the closest way I found to do such thing.
integrationtest:
stage: integrationtest
only:
- merge_requests
except:
variables:
- $CI_MERGE_REQUEST_TITLE =~ /^WIP:.*/
Unfortunately, Now the only thing missing is indeed the pipeline being triggered when WIP state changes.
Any idea to bypass this problem is more than welcome.
Thank you in advance :)
There is an open issue for you exact use case. There is a workaround with webhook integration mentioned in the last comment of this issue, maybe this will help you.
We have a fairly complex .gitlab-ci.yml configuration. I know about the new gitlab pipeline editor, but I can't find a way to 'simulate' what jobs get picked by my rules depending on the branch name, tag, etc.
On our jobs, we have a $PIPELINE custom variable to allow us to have different pipeline 'types' by using schedules to define this var to different values, like this:
rules:
- if: '$PIPELINE == "regular" && ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_TAG != null)'
or like this:
rules:
- if: '$CI_COMMIT_TAG != null'
Is there a way to 'simulate' a pipeline with different branch names, tags and variables so I can see what jobs get picked on each case, without actually running the pipelines (e.g. with a test tag, etc.). Or is there a better way to do this?
Thanks in advance.
Not quite, but this is close, with GitLab 15.3 (August 2022):
Simulate default branch pipeline in the Pipeline Editor
The pipeline editor helps prevent syntax errors in your pipeline before you commit. But pipeline logic issues are harder to spot. For example, incorrect rules and needs job dependencies might not be noticed until after you commit and try running a pipeline.
In this release, we’ve brought the ability to simulate a pipeline to the pipeline editor.
This was previously available in limited form in the CI Lint tool, but now you can use it directly in the pipeline editor. Use it to simulate a new pipeline creation on the default branch with your changes, and detect logic problems before you actually commit!
See Documentation and Issue.
New to Gitlab CI/CD.
What is the proper construct to use in my .gitlab-ci.yml file to ensure that my validation job runs only when a "real" checkin happens?
What I mean is, I observe that the moment I create a merge request, say—which of course creates a new branch—the CI/CD process runs. That is, the branch creation itself, despite the fact that no files have changed, causes the .gitlab-ci.yml file to be processed and pipelines to be kicked off.
Ideally I'd only want this sort of thing to happen when there is actually a change to a file, or a file addition, etc.—in common-sense terms, I don't want CI/CD running on silly operations that don't actually really change the state of the software under development.
I'm passably familiar with except and only, but these don't seem to be able to limit things the way I want. Am I missing a fundamental category or recipe?
I'm afraid what you ask is not possible within Gitlab CI.
There could be a way to use the CI_COMMIT_SHA predefined variable since that will be the same in your new branch compared to your source branch.
Still, the pipeline will run before it can determine or compare SHA's in a custom script or condition.
Gitlab runs pipelines for branches or tags, not commits. Pushing to a repo triggers a pipeline, branching is in fact pushing a change to the repo.