Techromancer
Techromancer

Reputation: 473

How to run an ad-hoc clean build in Azure DevOps?

I am new to using Azure DevOps builds/pipelines, as the source code for the solutions I need to build are in TFVC I am limited to using the Classic (i.e. UI) builds rather than YAML.

When I want to test changes to a build definition I sometimes want to run a clean build, i.e. ensure that sources and artifacts from earlier builds are removed before the new build run, yet leave normal builds (i.e. ones triggered by changes in TFVC) to be incremental so to make builds faster.

I am used to TeamCity which has a plethora of options with regards to managing source and artifacts retention between builds, including a simple "clean" check box when triggering a manual build. ADO Builds seems very limited in this regards and if I want to have a clean build it seems the only option is to change the build definition, select clean, run the build, then change the build definition again to remove the clean option.

Are there better ways to manage "ad-hoc" clean sources and artifacts in ADO Builds?

Upvotes: 2

Views: 1118

Answers (2)

Cece Dong - MSFT
Cece Dong - MSFT

Reputation: 31003

Build.Clean variable is deprecated, you can only use Clean option to clean local repo on the agent currently.

I'd like suggest you submit a user voice at website below, product team will evaluate it carefully:

https://developercommunity.visualstudio.com/content/idea/post.html?space=21

One workaround is adding a Post Build Cleanup task in the end of your pipeline, when you want to run builds incrementally, you can disable this task.

Upvotes: 1

Matt
Matt

Reputation: 4035

Those settings are either on/off. They wouldn't accept conditional run-time variables.

enter image description here

That being said, you might try leveraging the "Save as draft" option. It seems to create a DRAFT pipeline definition you could execute for your changes.

enter image description here

You could probably just flip it back to no clean before publishing. I don't really use that feature, but I am going to guess on the back-end it is using a different temporary definition id. That will probably mean on the build agent a new folder gets created under _work. If that is the case, you probably wouldn't even need to flip the clean sources since it will not exist the first run. It also probably means if this a self-hosted agent you will have doubled the work folder size and you might have to manage that clean-up after you are done.

enter image description here

If it does create the second work folder, this is probably preferable as it means you won't break the incremental build on the build directly following your test with clean. Whether you did that ad-hoc or through editing the build definition.

Upvotes: 1

Related Questions