Our structure for a release in azure devops is to
deploy our app to our DEV environment.
Kick off my Selenium (Visual Studio) tests against that environment.
If passes, moves to our TEST environment.
If fails/hard stop.
We want to add new piece/functionality, starts same as above, Except instead of hard stop. 5) if default step fails, continue to next step. 6) New detail testing starts (turns on screen recorder)
The new detailed step has 'Agent Job' settings/parameters, I have the section "Run this job", set to "Only when previous job has failed".
My results have been, that if the previous/default/basic testing passed, the detailed step is skipped. As expected.
But if the previous step fails....the following new detailed step does not kick off.
Is it possible because the step is set up that if it fails hard stop and does not even evaluate the next step?
Or is it because the previous step says 'partially succeeded'. is this basically seen not as a failure?
Yes, this is correct. Because failed is equivalent of eq(variables['Agent.JobStatus'], 'Failed') status. But partially succeeded is eq(variables['Agent.JobStatus'], 'SucceededWithIssues').
Please check here.
You may try custom conditions like :
in(variables['Agent.JobStatus'], 'Failed', 'SucceededWithIssues')
As an addition to the solution, a piece I missed was on the 'detailed' job, the 'Trigger even when the selected stages partially succeed', also needed to be checked, as well as the solution for the same step above.
Related
I want to kill hundreds of pipeline runs of specific pipeline and specific branch (without deleting either of them). Any idea how I can do it?
This can be done via a script which first calls all the runs of pipeline with
GET /runs?pipelineIds=&statusCodes=
and then cancels them one by one using:
POST /runs/:runId/cancel
Status codes of incomplete runs are 4000, 4001, 4005, 4015, 4016, 4022
Refer documentation for more details
Please, observe:
[Error]Failed to create ref refs/tags/dryrun-master-CI_64.0.0.25914-noat-test at 330dd52a89ed97f5dcd216bcf89e04b864247053.
[Error]Failed to create ref refs/tags/dryrun-master-CI_64.0.0.25914-noat-test at 330dd52a89ed97f5dcd216bcf89e04b864247053.
Created ref refs/tags/dryrun-master-CI_64.0.0.25914-noat-test at 330dd52a89ed97f5dcd216bcf89e04b864247053.
Running the build with the diagnostics does not actually produce any more output in this step.
The build url is https://dev.azure.com/Ceridian-dryrun/SharpTop/_build/results?buildId=1672629&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774&t=9ff468ea-e6fc-49e0-b3ce-f8332e9d6e3d, but I doubt it can be viewed by anyone.
I tried to reproduce it on a small repo, but apparently only this particular build is vulnerable.
How is one supposed to troubleshoot it? I am more than willing to inspect the source code of that task, but it is not amongst the tasks found in https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks. So, what can we do here?
Another weird thing - the duration of the step. It took 5 minutes to fail.
A certain task generates a ##[warning] and has a warning status.
It causes the final status of stage to be an orange exclamation mark.
I want to suppress this so that the stage will show as succeeded (green check).
Is there a way to achieve this?
Ive looked at the options at the task itself, but it only has ContinueOnError
*Edit:
Im talking about the Azure App Configuration Extension.
I've even delved into the path of updating the Build Result via REST API
but to unfortunaly, the PATH method doesn't seem to update the build result.
Update from OP
It's a known limitation/bug of task:
Azure DevOps Extension: Azure AppConfiguration - Partial Complete
Currently, by default the build result is "Failed" if anything failed to compile/build, "Partially Succeeded" if there are any unit test failures,ContinueOnError checked, and "Succeeded" otherwise.
It causes the final status of stage to be an orange exclamation mark.
According to your description, that task showing as "Partially succeeded" may due to you checked "Continue on error" option.
Continue on error (partially successful)
Select this option if you want subsequent tasks in the same job to
possibly run even if this task fails. The build or deployment will be
no better than partially successful. Whether subsequent tasks run
depends on the Run this task setting.
Please refer to this document for more info: Task control options
We have a scheduled release in Octopus that deploys the last known good release to Prod back to Prod.
However this has started failing because the artifact has fallen out of our retention policy - this we can fix by altering the retention policy.
The real issue is that when it failed no notifications were sent to the team because artifact collection happens before even the first step.
I have tested this with a dummy release that just has a single basic step and then a Slack Notification step for when it fails. However, we never get to the first step - let alone the slack step.
How can i hook on to this failure so that we know about these issues in future.
You have to follow below steps to achieve the same
Step 1) Add Email Template step # First : to inform that Build is triggered
There is a setting in that called : Start Trigger set it to Run in parallel with the previous step so email will be triggered while your artifacts are downloading
Step 2) Add Email Template step # Last : to inform that build failed
Just change the setting Run Condition set it to : Failure: only run when a previous step failed
so when your deployment get fail, It will notify the same. You can add the cause of failure in email body using inbuilt variables also.
In a certain Jenkins config, I wish to trigger another configuration as post build action.
I want to pass as one of the parameters the current build status.
IE: a string / int that represents the status (SUCCESS/FAIL/UNSTABLE).
I have 2 options to create post build triggers:
Using the join plugin
Using the trigger parameterized build in post build actions
I wish there was some kind of accessible env variable at end of run...
Have any idea?
Thanks!
Here is a simple solution that will answer most cases:
Use 'Trigger Parameterized Build' plugin, and set two triggers -
'Stable or unstable but not fail'
'Fail'
Each of those triggers should run the same job - let's call it 'JOB_B'.
For each of the triggers, pass whatever parameters you like, and also pass a user-defined value:
for trigger '1' use: JOB_A_STATUS=SUCCESS
for trigger '2' use: JOB_A_STATUS=FAIL
Now, all you need to do is test the value of ${JOB_A_STATUS} from JOB_B, to see if it is set to 'SUCCESS' or 'FAIL'.
Note this solution does not distinguish between 'stable' and 'unstable', but only knows the difference between 'fail' and 'success'.
Good luck!
You can check for status using Groovy script in post-build step via Groovy Post-Build plugin that can access Jenkins internals via Jenkins Java API. The plugin provides the script with variable manager that can be used to access important parts of the API (see Usage section in the plugin documentation).
For example, this is how you can output build result to build console:
def result = manager.build.result
manager.listener.logger.println "And the result is: ${result}"
Now, you can instead use that value to create a properties file and pass that file to Parameterized Trigger post-build step (it has such an option).
One caveat: I am not sure if it is possible to arrange post-build steps to execute in a particular order to ensure that Groovy post-build step runs before the Parameterized Trigger step.