Gitlab pipeline - run the script with a rule - gitlab

I want to send a slack notification as soon as trigger the pipeline build manually.
Steps I am following:
Go to your project’s CI/CD > Pipelines and select Run pipeline.
Choose the branch you want to run the pipeline for.
Input the variable and its value in the UI.
Click on the Run pipeline button
From the documentation I see:
How the pipeline was triggered. Can be push, web, schedule, api, external, chat, webide, merge_request_event, external_pull_request_event, parent_pipeline, trigger, or pipeline. For a description of each value, see Common if clauses for rules, which uses this variable to control when jobs run.
In this init stage I want to execute a script only when I run the pipeline using the above steps
init:
stage: init
environment: $DEPLOY_ENVIRONMENT
script:
- bundle exec fastlane slack_build_start_summary
rules:
- if: $CI_PIPELINE_SOURCE == "trigger" // also tried with "pipeline"
when: always
But I can't see this stage in the Gitlab pipeline stages.
I want to know which CI_PIPELINE_SOURCE ("trigger" or "pipeline" or something else?) I need to check when I trigger the pipeline manually from Gitlab using the above steps.

I got the answer here from the documentation
web -> For pipelines created by using Run pipeline button in the GitLab UI, from the project’s CI/CD > Pipelines section.
So I need to use:
- if: $CI_PIPELINE_SOURCE == "web"

Related

How to run a pipeline manually without getting "No stages / jobs for this pipeline"? [duplicate]

My GitLab pipelines execute automatically on every push, I want to manually run pipeline and not on every push.
Pipeline docs: https://docs.gitlab.com/ee/ci/yaml/#workflowrules
I tried this in
.gitlab-ci.yml
workflow:
rules:
- when: manual # Error: workflow:rules:rule when unknown value: manual
as mentioned in the documentation, I think you should specify a condition that tells Gitlab to not run the pipeline specifically on push events like so:
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "push"'
when: never # Prevent pipeline run for push event
- when: always # Run pipeline for all other cases
Well, this was all from the official documentation but I hope that this may help you :)
We can define your jobs to be only executed on Gitlab.
The web option is used for pipelines created by using Run pipeline button in the GitLab UI, from the project's CI/CD > Pipelines section.
only:
- web
Here is the solution I cam up with:
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "web"'
when: always
- when: never
This specifies that it will only run if you click the "Run Pipeline" button in the web UI. In all other cases it will not be triggered.
the when section should not be within rules
workflow:
when: manual

how to add manual intervention in build pipeline

i have a build pipeline i want to add mannual intervention in the pipeline and when that manual intervention is done the user can click on resume the pipeline but i want to do this in build pipeline.
i checked in this https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation?view=azure-devops&tabs=yaml but it looks like we need to do using stage pipeline in release pipeline. but i want this to happen in build pipeline
We seem have not such task for build pipeline, especially classic build pipeline.
If you want to add manual intervention in a build pipeline, you can try to set up this pipeline with YAML and add this run the Manual Validation task in an agentless job.
However, it might not be possible if you want to pause a running agent job in the build pipeline. Maybe you can try run the pipeline on a self-hosted agent with interactive mode.
[UPDATE]
You should use the Manual Validation task in an agentless job in the YAML pipeline, not in the classic build pipeline.
To set up an agentless job in the YAML pipeline, you need to set the value of 'pool' key to ne 'server'.
jobs:
- job: agentless-job
pool: server
To view more details, you can see "Server jobs".
To add a manual validation task in pipeline without creating a agent-less job you will need to define pool: server on the top of your steps. as below.
I got this from by referring to canary deployments but have tested the same works for rolling deployment and probably other steps introduced in the pipeline.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops
pool: server
steps:
- task: ManualValidation#0
timeoutInMinutes: 1440 # task times out in 1 day
inputs:
notifyUsers: |
youremailadress#hotmail.com
instructions: 'Please validate the build configuration and resume'
onTimeout: 'reject'

Will Gitlab trigger all jobs that listen on a branch change when I run pipeline manually

I have a pipeline that contains several jobs triggered by changes on a branch:
deployDev:
only:
- dev
script:
- ...
deployProd:
only:
- master
script:
- ...
If I now hit the "Run pipeline" button in the GitLab UI, will it trigger these jobs or will it only trigger the jobs that specify when:manual ?
And how can I make sure that deployDev and deployProd do not run when I run a manual deploy?
I have checked here: https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic, but I'm unsure.
It'll run all jobs corresponding to the branch and will wait for manual action for manual jobs.
So your deploydev will run against your development pipeline and other job will run only in production pipeline
I'm a bit confused what you are trying to achieve from your comment as well, however...
If I now hit the "Run pipeline" button in the GitLab UI, will it trigger these jobs or will it only trigger the jobs that specify when:manual ?
As #Prashanna has said, It'll run all jobs corresponding to the branch and will wait for manual action for manual jobs.
If you do not want deployDev and deployProd to appear in the Pipeline when pressing the Run Pipeline button, you can use:
only:
- master
except:
- web
from the link you showed https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic: web -
For pipelines created by using Run pipeline button in the GitLab UI, from the project’s CI/CD > Pipelines section.
The above job would then only appear in the Pipeline, when it is the master branch, and when it has not been triggered by the Run Pipeline button.

Gitlab-CI : triggering a stage based on the Status of the previous stage

enter image description here
Hello - I'm using Gitlab 10.x Enterprise version.
This is in the context of a Production deployment to an environment having eight servers. The requirement is to deploy to one server first, and then after couple of days do a deployment to the remaining servers with the press of just one button.
Pipeline Stages:
Release-Tag-Creation -> Production-OneServer-Deployment -> OneButtonPush -> DeploytoAllServers
Question:
How can I tie the dependency between the stages "OneButtonPush" and "DeploytoAllServers"?. "DeploytoAllServers" stage should be kicked-off only when the Status of the job in the "OneButtonPush" stage is successful. "DeploytoAllServers" stage will have parallel jobs to deploy to each server.
I made few attempts based on the Gitlab CI documentation, but wasn't successful. Also, can the concept of Rolling deployment used in the context of GitLab-CI.
Thanks!
In Gitlab CI, the stages are run one after another. Each stage can have multiple jobs which run in parallel.
As per your use case, you'll need to have different stages each for Release-Tag-Creation, Production-OneServer-Deployment, OneButtonPush and DeploytoAllServers. You can have manual triggers for particular jobs (OneButtonPush in your case) by specifying when: manual in the job definition.
By default, if there is a job awaiting manual trigger, jobs from further stages will start executing considering the job with manual trigger as successful. To change this behavior one will need to use allow_failure: false. Mode details on allow_failure over here
If you want to run the Stage only after then specific one get successful you can use the needs
Example
image: maven:latest
stages:
- deploy_dev_lambda
- test_dev_lambda
deploy_dev_lambda:
stage: deploy_dev_lambda
image: maven:latest
script:
- ./deployLambda
environment: dev
variables:
TARGET_ENV: "dev"
TAG_NAME: main-$CI_COMMIT_SHORT_SHA
test_dev_lambda:
stage: test_dev_lambda
needs:
- deploy_dev_lambda
script:
- ./testLambda
So test_dev_lambda only run after the deploy_dev_lambda stage and if stage deploy_dev_lambda fails test_dev_lambda wont get executed.

How do I establish manual stages in Gitlab CI?

I'd can't seem to find any documentation of manual staging in Gitlab CI in version 8.9. How do I do a manual stage such as "Deploy to Test"?
I'd like Gitlab CI to deploy a successful RPM to dev, and then once I've reviewed it, push to Test, and from there generate a release. Is this possible with Gitlab CI currently?
You can set tasks to be manual by using when: manual in the job (documentation).
So for example, if you want to want the deployment to happen at every push but give the option to manually tear down the infrastructure, this is how you would do it:
stages:
- deploy
- destroy
deploy:
stage: deploy
script:
- [STEPS TO DEPLOY]
destroy:
stage: destroy
script:
- [STEPS TO DESTROY]
when: manual
With the above config, if you go to the GitLab project > Pipelines, you should see a play button next to the last commit. When you click the play button you can see the destroy option.
Update: Manual actions were Introduced in GitLab 8.10. From the manual "Manual actions are a special type of job that are not executed automatically; they need to be explicitly started by a user. Manual actions can be started from pipeline, build, environment, and deployment views. You can execute the same manual action multiple times." An example usage of manual actions is deployment to production. The rest of this answer applies to Gitlab 8.9 and older only.
Historical Answer:
It does not appear as though manual deploy/release was available in Gitlab in 8.9.
One possibility is to have a protected branch which triggers a release. See info about protected branches here: http://doc.gitlab.com/ce/workflow/protected_branches.html
Essentially a protected branch would allow you to Create a branch (testdeploybranch) which only you would be allowed to merge code into. Whenever a commit to dev would pass the Gitlab CI tests and deploy jobs, as well as your manual review, you could merge that commit into the protected branch to trigger the release. For this branch you can then set up a special release job in Gitlab CI using the only option in the .gitlab-ci.yml job definition. Read more here: http://doc.gitlab.com/ci/yaml/README.html
So something like this:
release:
only: testdeploybranch
type: release
script: some command or script invocation to deploy to Test
This might not be exactly what you are after, but it does allow you to do manual releases from Gitlab. It does not provide an easy way to manually do the same release procedure manually for different servers. Perhaps someone else might be able to expand on this strategy.
Finally, we have Gitlab CI manual actions that were introduced in GitLab 8.10.

Resources