I am trying to rollback in release pipeline when the latest release gets fail it will revert at last successful. I added a PowerShell task which only runs when previous tasks have failed and script which is triggering last successful but the problem is it start redeploying stages randomly not sequentially.## Heading ##
In my scenario I have 3 stages, at the end of each stage, I have added a PowerShell task that will trigger only when the previous task has failed and wrote a script accordingly to trigger last successful release. so it will trigger all the stages in the last release because I haven't got any API or command to trigger release by id. I have an API which triggers only stages. All the stages are queueing sequentially but running randomly.
enter image description here
Since you are using the Release Pipeline, I suggest that you could use Auto-redeploy trigger option for each stage.
When the stage fails, it will re-deploy the last successful release of the current stage.
For example:
Set Auto-redeploy trigger option for stage 2 -> Stage2 fail -> Auto redeploy the last successful Stage 2
Update:
From you requirement, you could try to use the Release Orchestratortask from Release Orchestrator extension. This task could be used to manage the release.
Here is the example:
You could use this task to replace the powershell task. This task supports to select the re-run release name and the target stages.
It can also be sorted according to the input stage order.
Note: you also need to set Maximum number of parallel deployments as 2 for each stage -> Pre-deployment conditions-> Deployment queue settings.
Related
I have a Gitlab CI pipeline schedule and noticed that pipelines are not running (anymore).
When starting the schedule manually via the UI (<repo-root>/-/pipeline_schedules) it shows the following
However, there is not pipeline started and no error message is provided.
What can I do in this situation?
The success message is misleading in the sense that one might thing the pipeline was actually created, although it only means that a pipeline was scheduled.
There are various reasons, why a schedule cannot run (anymore).
This can be for example because of conflicting rules or outdated fields in your yml caused by breaking changes due to Gitlab upgrades.
To get to the root of the problem why your pipeline did not run you can trigger a pipeline manually and set the
CI_PIPELINE_SOURCE to hold "schedule" as value.
To do so, go to <repo-root>/-/pipelines/new, set your target branch or tag and the variable as follows
Additionally, you may want to provide further variables required to properly simulate your problematic schedule via the manual run.
Next hit Run pipeline and you should observe an actual error message why the pipeline could not run.
I am using azureml schedules to schedule azureml pipelines. When I want to update a pipeline I am disabling the schedule, deleting and re-publishing the updated pipeline and re-creating the schedule. However every time I do this, the schedule.create command sets the pipeline running as soon as it is published (instead of just setting it to run at the provided recurrence intervals).
Can I disable this behaviour? I dont need the pipeline to automatically run every time I commit and re-run the publish pipelines
We have a Release Pipeline that is being trigger after a build pipeline is succeded.
We have been updating the build pipeline and adding additional stages to it that does not affect the Release process. The problem is, that sometimes the additional stages are failing, causing the Release pipeline not to be trigger, but the original initial stage is succeded and the release could still be done.
Is there a way to set up the Release Pipeline to trigger after the Build Initial Stage succeded? I can only find the build, but would be ideal to set the stage too.
You can use for instance extension Trigger Azure DevOps Pipeline.
You can third stage
initial stage
additional stage - this should go when initial stage succedded
trigger stage - this should go when additional stage failed
I made one release pipeline with one stage for deployment and second stage of Selenium test case as per the image.
Please tell me how can i revert the deployment when Selenium test case got failed. Means when my second stage fails my first task also should be reverted. Please help.
You can run the previous successful deployment if something fails. Will that solve your case?
Below you can see an example of a post deployment condition and a rerun of the last successful release.
Please tell me how can i revert the deployment when Selenium test case got failed.
The most effective way is that you could manually choose the previous record of successful release, then you could use the "Redeploy" option to deploy the stage (dev stage) again.
Additional info:
I set the "Auto-redeploy trigger" (Deployment to this stage fails) in Stage 2. When the stage 2 is failed, it only re-deploys the previous successful Stage 2. The Stage 1 will not roll back.
Hope this helps.
Basically I am looking for the retry button for the pipeline triggered, but all I see is a retry button for the individuals jobs of that pipeline. I don't want to have to push a commit just to retry a pipeline.
Reference screenshot
You can retry the latest push on the pipeline by going to:
CI/CD -> Pipelines -> Run Pipeline -> Select the branch to run.
Otherwise, as you've mentioned, you'd have to manually press the retry button for each individual job for the pipeline (for a pipeline that isn't the latest).
GitLab 15.1 (June 2022) should help:
Retry a downstream pipeline from the pipeline graph
Previously, to retry a downstream pipeline, you had to navigate to the pipeline and select retry.
This worked, but was a challenging experience when there were multiple
downstream pipelines.
You had to go into every individual pipeline you
wanted to retry and find the retry option, which was cumbersome.
In this release, we’ve improved the user experience by adding an option to retry downstream pipelines directly from the pipeline graph, without the need to go into each pipeline’s details page.
See Documentation and Issue.>