Is there a way of retriggering a successful child pipeline in gitlab ? I don't see any retry button in trigger job, which we otherwise see in normal pipline job. Is there a way/workaround to get an option to do so ?
I went through the gitlab doc, it only talks about retrying failed jobs in child pipeline.
That is currently (Q4 2022) not supported yet.
(And retry: is indeed only for failed job)
It is requested by issue 29456:
Ability to rerun a successful pipeline via "Retry" button
Not only failed pipelines sometimes need a rerun but also successful ones:
If your tests are unreliable and you are sceptical that the test success is repeatable
If your jobs depend on outside factors
If your job depends on some predefined CI variable which can change without a code change
So in general, a pipeline should show the retry button even in case of a success. Then, all jobs should be retried again
The currently suggested workaround of CI / CD -> Pipelines -> Run Pipeline does not always work, especially not for merge request pipelines.
In my case, I have all jobs defined as only: merge_requests and "Run Pipeline" responds with the error "No stages / jobs for this pipeline"
Related
I was wondering and could not find a solution to our problem.
We have many CI pipelines running in scheduled times and we need to add a job in case of early job failure.
For example lets say that in the attached picture job "deploy-job1" failed (not like in the picture)
We want to have a "sleeping job" that will be activated and run only when a previous job did not succeed.
Gitlab pipeline
Are there any suggestions on a way to handle this kind of a task?
We have tried handle this within the scripts we are running but we want to have general "sleeping job" that will be similar to all stages
Something like this might help:
.sleeping_job:
needs: deploy-job1
when: on_failure
# do stuff
Is there a way to test pipeline changes on a stage that has finished running? It would be super useful when a stage has failed and instead of running the entire pipeline to test your changes, you could trigger a rerun of the stage with the updated yml file.
By definition, re-running a stage means running it the same way as it was run initially. When you think about, this is the very desired behaviour.
For pipeline development purposes, I would recommend cloning the pipeline and removing all unnecessary steps. Then work in this minimal/debugging pipeline for faster feedback.
I have an upstream and a downstream pipeline. Unfortunately, I cannot easily re-trigger a downstream pipeline run via the upstream pipeline:
Expected situation:
Actual situation:
The upstream pipeline is responsible for creating the build, and then triggers the downstream pipeline for deployment or undeployment activities. Upstream sets a variable called ACTION in order to inform the downstream pipeline which stage is expected to run.
My goal is, to be able to re-run deployments and undeployments as often as I want.
How can I re-run the downstream pipeline with either the "deploy" or the "undeploy" parameter set, triggered by the upstream pipeline?
You cannot "retry" bridge jobs from the upstream pipeline, unfortunately. This is a known limitation in GitLab.
The only way to work around this is to re-run the downstream pipeline is to manually retry the pipeline/jobs from the downstream pipeline's interface. However, this only covers cases like failure of a downstream job. Retrying can't change the pipeline structure itself (like what jobs are included) because rules: are only evaluated at pipeline creation time. Even if you change variable settings and retry a pipeline, you won't see any difference due to rules:.
My advice would be to not use this - if: $ACTION rule. Instead, always include both jobs in the pipeline and set the undeploy job as the on_stop parameter for the deployment job.
I have a few independent scheduled CI jobs.
Check that the infrastructure matches Terraform code.
Check for npm vulnerabilities.
Check that external APIs pass tests.
These are not hermetic. They do not test the fitness of the code in isolation. They could succeed at commit 12345 and then fail at commit 12345 and then succeed again.
I run these daily.
Gitlab lacks the ability to have multiple pipeline types (unlike, say, Buildkite), so I use a variable to control which steps run.
However, I am left with the problem that these checks interfere with the main passed/failed status of commits.
For example, if the Terraform infra check fails, then it's broken and people are notified and whoever is the next to push is informed they fixed it.
These kinds of checks can't be that uncommon, right? How should thse be managed?
It sounds like you're looking for the allow_failure keyword.
https://docs.gitlab.com/ce/ci/yaml/#allow_failure
When allow_failure is set to true and the job fails, the job shows an orange warning in the UI. However, the logical flow of the pipeline considers the job a success/passed, and is not blocked.
job1:
stage: test
script:
- execute_script_that_will_fail
allow_failure: true
I have a an Azure Pipeline A, that executes a deployment to my Salesforce org in the event of a PR merge.
My problem statement is,
I am not able to restrict the execution of this pipeline such that it executes only after the previous execution of the same pipeline has completed.
In other words, if this pipeline is triggered by multiple PR's, then I would want only once instance of the pipeline to run. The next one should wait until the previous run has been completed.
Is there a way to achieve this?
You can enable "Batch changes while a build is in progress" option to execute one pipeline at a time.
If your question was on Release Pipeline, you can achieve this through specifying number of executions in the "Deployment queue settings" under Pre-Deployment conditions for the particular stage.
If you are using YAML you should be able to use the following trigger:
trigger:
batch: boolean # batch changes if true; start a new build for every push if false (default)
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema#triggers