I may be missing something here but dont know what. As shown in the images, my build artifact is created from 'dev' branch and has 'dev' tag but VSTS is incorrectly evaluating the condition (or my expectation in wrong ).
VSTS Build Artifact
VSTS Release Trigger
There was a space in name of the tag which was not apparently visible on build artifact
Related
We are using Build Pipeline in Azure DevOps to create a Deployment Artifact. Typical steps in such pipeline are:
Build Solution / Project
Copy dlls output into $Build.ArtifactStagingDirectory
Publish Artifact from $Build.ArtifactStagingDirectory
I just wonder if I can rely on the fact, that on start of each Build the Build.ArtifactStagingDirectory is empty. Or should I clean the folder as first step to be sure?
From my experience the folder was always empty, but I am not sure if I can rely on that. Is that something specific to Azure hosted Agent and maybe by using custom Build agents I have to do manual clean-ups of this folder? Maybe some old files from last build could remain there? I did not found this info in documentation.
Thanks.
I think that the main idea of this variable $Build.ArtifactStagingDirectory is to be a clean area so you can manage the code you're pushing from your repo. As far as I know, there is no explicit information on documentation talking that this folder is empty at every new build, but there are a few "clues":
You can see at the Microsoft's Build Variables documentation that Build.StagingDirectory is always purged before each new build, so you have a fresh start every build.
In the documentation above you have a few cases where it explicitly cites that some folders or files are not cleaned on a new build, like the Build.BinariesDirectory variable.
I've run a few build and realeases pointing to my Web App on Azure, and I never saw an unwanted file or folder that was not related to my build pipeline.
I hope that helps.
I have a build set up in VSTS and at the end I want to Publish my Artifacts to VSTS for releasemanagement and I want to Publish my Artifacts to a file share for other purposes. So I have 2 Publish Artifacts tasks.
To VSTS
To FileShare
I get this error
It doesn't matter in which order I put the tasks. When I put file share first then to VSTS will fail and when I put VSTS first the publish to file share fails.
When I do a commit and a build is started automatically it sometimes works. When I manually start a second build I get the error.
Here is the complete build log: Build log
It's telling you the error: Artifact 0.1.0-unstable.18 already exists.
You can't publish two artifacts with the same name. You will have to uniquely identify each artifact.
I have a YAML build definition in VSTS working fine for some times.
I recently started to tag my repo from my release definition using this task.
It is working pretty fine, except that each time this task add a new lightweight tag to my repo, it also trigger my CI on that tag. The branch associated to the build is refs/tags/mytag.
I tried to prevent that behavior by adding trigger branch filter in my YAML definition:
trigger:
branches:
include:
- master
- release
exclude:
- refs/tags/*
But my build is still being triggered.
Any idea about how to prevent triggering a build definition when creating a new tag?
Note
I also tried by creating a Tag myself from the VSTS portal (which in that case is NOT a lightweight tag). The build is still being triggered, but in a different way because it is failing with error message Expected a Commit, but objectId f768714f0bac926164dea5b77e696da7a73db426 resolved to a Tag.
Also the version string is not properly computed in that case and result in a simple int instead of my formatted version string.
For now, there has no options to specify tags include/exclude to trigger the CI build.
And there has the user vice Trigger build when pushing tag to git which suggest the feature to specify tags in CI build, you can vote and follow up.
The workaround for now is override YAML Continuous Integration trigger from Triggers Tab:
In your YAML build definition -> Triggers Tab -> Override YAML Continuous Integration trigger from here -> Include the branches you want to trigger the branch (master and release branches for your situation) -> Save build definition.
Now only commits are pushed to master or release branch will trigger the CI build, and tags creation will not trigger CI build.
Is there anyway to execute action in a pipeline stage based on a condition.
I mean for example, when the pipeline releases, it sources the source files at the source stage, and in the build, deploy or other stages are executed if a file exists in the artifact or is not empty...
In fact I would to execute the whole pipeline stages only when my condition is met...
Till I didn't see how to well achieve this.
What I think now to play on approval feature, I don't what you think and if one here has already had the same requirement.
The simplest way to achieve this is likely to add a Test stage to your pipeline. You test can simply check for the desired file in the build artifact, and simply fail the check if the file isn't there, which would halt the pipeline.
Usings tests with AWS CodePipeline
Im trying to figure out how to chain multiple 'promotions' (by a user clicking) whilst ensuring that ever build in the chain is not queued. By current setup is as follows, NOTE as my application is a white label the configuration described below is repeated for every site.
Build & Test - Creates zipped artifact
Deploy to Testing - Has artifact and snapshot dependency
Deploy to Staging - Has artifact and snapshot dependency
Deploy to Production Has artifact dependency
When promoting to production i want to do this across all websites (without having to manually click promote on each build).
I am currently trying the following strategy, to set the 'deploy to production' build to have a Artifact dependency, without a snapshot dependency so it doesn't queue down the chain. I have set the artifact to depend on the 'Build & Test' configuration to gain access to the zipped project and i have set it to build with a specific build number referencing a parameter in the production build.
After doing some googleing i found out that i am able to get the stagings build number using the rest api as follows:
http://teamcity_url/httpAuth/app/rest/builds/buildType:build_configuration_id/resulting-properties/build.number
And this works great, however i don't understand how i can get this value into the parameter?
Also i dont know if my approach is correct? is there a better way?
Set up the artifact dependencies chronologically (Build -> Test -> Staging -> Production) and all your snapshot dependencies to Build & Test. Depending on exact needs you might have a snapshot dependency on both Build and the one your artifact dependency is on.
Also make sure you enable "Do not run new build if there is a suitable one. This should keep it from queuing down the chain without intention.
Using the build chain tab will be important because the main project page only shows the last build ran. So clicking run from there will que the chain because you are asking for a new build, even though to you it might feel like your asking for the next step to be ran. The build chain tab helps keep things clear.