It is not clear what changes will invalidate the pipeline and prompt snakemake to re-run the workflow.
Does change in input, intermediate output or custom script re-run the pipeline? In my experience changing intermediate output and custom script does not invalidate the pipeline and having that feature may improve reproducibility.
Related
I have scheduled build pipeline thats autmatically triggered by changes in source code. Basically I want to know which changesets got into build before pipeline started to execute.
You can use the predefined variable $(Build.SourceVersion) to get the changeset that triggering your pipeline. For detailed information, please refer to this document.
You can use this variable as part of the pipeline definition or value in the script that you want to run in pipeline. When the pipeline is triggered, this variable will be assigned by the system automatically.
I've been working on a cronjob pipeline that runs at x time of the day on the develop branch, but I've been running into an issue that has been problematic.
So for example, I have pipelines A, B and C. The pipeline that runs the cronjob should only trigger on pipeline A. Although this does work, it also triggers pipeline B in parallel which is completely unintended and not ideal as that pipeline's functionality is different.
Is there a way to configure the YAML file in a way so only pipeline A gets triggered and no other pipelines get triggered in the process?
The first thing I would check will be the cron settings for other pipelines. If no YAML cron is defined I would go and check the GUI settings.
Press edit
and then triggers.
under scheduled you can locate if cron settings are defined on GUI.
Then you could also deactivate pr triggers and branch triggers for the pipelines that you do not want to get triggered as a second step of troubleshooting.
Is there an inbuilt variable in Azure pipeline that checks if a build has run more than once?
I want to add a condition where i skip the step if build has run more than once.
As you can see ive commited once which triggered the build then i ran a manual build on the same commit hash so i want to know if there is a way to find out how many times it ran so i can add condition to one of my steps in the pipeline to skip if its > 1
I can see we have predefined variables for failed builds but how about normal build attempts
System.JobAttempt
and
System.StageAttempt
As a part of Azure pre-deployment condition I need to include a pause which should prompt for user input variable which can be used inside the task.
I need to update the variable in the Azure release task dynamically during run time. For that Is there a way to implement user prompt so that the variable will be overided.
I am afraid this is impossible to update the variable in the Azure release task dynamically during run time.
First, Azure devops does not support prompt for user input.
Second, when we queue a build/release pipeline, all the related data like variables, settings are loaded into the compiler, even if we modify the variable, the modified variable will not be reloaded into the compiler. We have to restart the compiler to recompile the modified variables.
So, it is impossible to update the variable in the Azure release task dynamically during run time.
To resolve this issue, we have to find other workarounds to solve this issue. For example, Usig Settable at release time:
In this case, we could update the variable when you queue the release pipeline.
Or we could use the Logging Command during the release pipeline to update the variable.
If above not resolve your question, please share the reason and situation why you want to update the variable in the Azure release task dynamically during run time, we can try other solutions.
I use azure pipeline for build my solution.
Aftere build I need to generate and upload multiple packages with different assets. Packing implemented as a number of additional tasks in my agent job.
But I need ability to generate only selected packages or all packages based on specified arguments.
What is the best way to achieve this?
Ideally, it would have 2 pipelines. The first is automatic project build. And the second should use the result of the first and be able to repeatedly start manually with the desired parameters to exclude project rebuild. But I do not know how this can be implemented.
Not sure if I understand the question correctly, but two possible answers would be:
Classic pipelines, with build pipeline for project build and release pipeline for uploading the artifact(s) that build generates, if using release pipeline is applicable. Release pipeline can have a cd-trigger for the first run, and redeployed manually after that. If need to change release variables for subsequent deployments, you can create a new release with the same build artifact.
Multi-staged pipeline, with build and upload as different stages, manually redeploy/rerun the upload stage when needed. Build phase generates deployable pipeline artifact(s).
Somehow I think you're looking for more elaborate solution, as you state that you're already using pipelines. So how about creative use of conditional tasks (https://learn.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml) using pre-defined variables like Build.Reason (with value 'Manual') to exclude the execution of certain tasks in some runs. Then group tasks you want to re-use into either build templates or task groups.