Implementing a CI/CD pipeline can be intimidating if you are used to a manual release process.  I have heard the concern that tools like Azure DevOps are not flexible enough for more complex build procedures.  Even the term pipeline certainly suggests moving in a straight line through your process, which doesn’t seem very adaptable.  However, there is always a way to make the build process work for your unique needs and gain the benefits of a CI/CD pipeline.  I recently encountered a situation where we only wanted certain tasks to be run inside our pipeline depending on the state of the build.  This was relatively straight forward to implement using Azure Pipelines built in custom variables and conditional logic.

Set variables

While most people know about Variables in pipelines as a way to store environment specific or secure information, it can also be a great way to share information between tasks in a running job.  Anything written to the console during a job with the correct format will modify the variable in the pipeline.  This can be then used in future tasks.

In my case, the build had a configuration file that need different sections added based on files that were modified in last build.  A powershell script was created to move that file and set the right build variables.  A simplified example is below:

 

 

This script will move any .MD files found in the solution and set the file count variable to how many files were moved.  We will use this amount as a condition for a future task.  Note the final line to write output of variable.  Azure DevOps variables modified by logging to console only take effect for future tasks, so this will still have original value.  However, this task will display correct value.

 

Conditional Values

Now that we’ve set our variable, we can act on it for future tasks.  In this example, I’ve made the publish artifacts task only trigger if a certain amount of files are present.

There are a variety of built in conditions that can be used as well as various conditional expressions you can use with either the system variables or your own custom variables.  Now that our pipeline is set up, lets run through an example.  With the default repo I create, there is just one README.md file, which won’t trigger the threshold for a publish.

Therefore, our first example will skip our publish step.  You can see the reason in the description.

Now, if we add a Test.MD file to have another file meet our criteria, which will trigger a new build.  When we look at the results of this build we can see publish task ran correctly.

 

Conclusion

Using these tools you can control what parts of your build and release process run based on the state of the repo or the results of previous steps.  While some CI/CD pipelines can be simple, there are usually unique elements of every organization that require some customization.  Being aware of the tools available to you is always useful when deciding the best course of action.  In determining the best path forward, New Signature is here to help.