I've created a VSTS build with an Azure PowerShell script that works perfectly. The issue comes when I try to call the exact same script (exact same file in a git repo) from my VSTS release. When the script runs I get no errors but the environment variable, $Env:BUILD_SOURCESDIRECTORY, is empty. Like I've said before the VSTS build executes perfectly but I'm unable to run the exact same code in a VSTS release.
Your problem is that you are using a Build variable inside a Release. This just isn't going to work, it's empty because it simply doesn't exist in a release context.
Even if you could do this, I wouldn't suggest you do this. Your release should rely solely on artifacts, not build variables when the artifact was generated. You could certainly define this variable in your artifact, and access from the release, but I would highly suggest you not go down this path, as it's a really bad practice.
You didn't mention it, but if you stated why you think you need access to a build variable, perhaps we could help you find a better solution here.
Not all variables that are available in Build are available in Release. The Sources directory is available during the build. If you want to keep it available during Release, you should create an artefact in the Build, name it Sources. That way the artefact will be available in Release through its respective variables.
Overview of variables available in:
Release
Build
Related
I have a continuously triggered Azure DevOps release definition that deploys a compiled Angular app to a web server and also runs Cypress e2e tests. The Cypress tests must run against the source code, so that means I need an artifact that is able to reference the same commit that was used to create the compiled app.
I created a GitHub artifact that gets the source code, but I can't figure out how to automatically change the branch/commit to whatever was used for the compiled app (it could be any branch and the names are not known ahead of time). Azure forces me to enter a hard-coded branch name and it does not accept wildcards or variables.
If I could simply use the variable ${Release.Artifacts.{alias}.SourceBranchName} for the default branch, I think I'd achieve my goal. Since Azure doesn't allow this, is there an alternative approach that accomplishes the same thing?
Note 1: The "Default version" dropdown has an option "Specify at the time of release creation", but that is intended for manual releases and can't be used for triggered ones, so no luck there.
Note 2: I looked into publishing the source code as an artifact, but it currently has almost 70,000 files and it adds more than an hour to the build step, so that also is not an option.
When you use the Release Pipeline artifacts, you are not able to set the pipeline variable in the Default branch field. This field only supports hard-coded.
is there an alternative approach that accomplishes the same thing?
The variable:$(Release.Artifacts.{alias}.SourceBranchName) can be used in the Release Pipeline agent job.
Workaround:
You can remove the Github artifacts and then add a Command Line task/PowerShell task/ Bash task to run the git command to clone the target repo.
For example:
git clone -b $(Release.Artifacts.{alias}.SourceBranchName) GithubRepoURL
PowerShell sample:
In this case, the script will use the same branch as Build Artifacts to checkout the source code.
How to get the path to a script (not procedure) in Azure DevOps build?
I'm trying to get the path to either my solution or project file to use in Visual Studio database project PostDeployment.
Works locally
In the Script.PostDeployment.sql file in a Visual Studio Database project I have the following code
SELECT #solutionDir = REPLACE('$(SolutionPath)','MySoulution.sln','');
SET #File = #solutionDir + 'myScript.sql'
-- and here I can use the #File
When I do a local publish/or build I can use the variable/macro $(SolutionPath) where I get the full local path to the solution.
With that I can point to the script I need to access.
Fails in AzureDevops
But Azure DevOps build doesn´t have the $(SolutionPath) macro and I get the following error
SCRIPT.POSTDEPLOYMENT.SQL(17,32,17,32): Build error SQL72008: Variable SolutionPath is not defined.
So I need a way (in AzureDevops) in the build step to get the path to the scripts.
What I have tried
I have tried all kinds of macros that just don't seem to work.
I have tried to work with predefined variables
I tried to use SqlCommandVariableOverride but it seems to have gone missing from the database project some time ago.
Questions
How can I add $(SolutionPath) (or something else) to my build step so this works both locally and in Azure DevOps build?
Is there another way to get a solution or project url to the postdeployment SQLCMD file?
Is MSBuild Extension Pack something I should look at? I will if it is my only option.
p.s
I also created a ticket for this in Azure Pipelines Tasks since they don´t seem to be that active in answering and I can't wait.
e.s
I asked the same question at developercommunity.visualstudio.com. Lets hope somebody there will be able to answer the question. If so I will update this question with an answer.
So first double check that your build is publishing the artifacts. there should be a blue button in the top right corner of your build that says "artifacts". To have access to the artifact you need to do an archive task after you do the build and point it at
$(Build.ArtifactStagingDirectory)
Then I would recommend not using SQL to make direct references to the filesystem for the build server. If this is absolutely necessary then you should use environment variables.
I would recommend setting up a release pipeline for deployment of the SQL script. Release pipelines are really designed for deployment, whereas builds are for compilation.
To configure the release, point it to the artifact and then you can access that artifact by $(System.DefaultWorkingDirectory)/**/*.zip then run whatever commands you want to do to process that.
We have a requirement to update a text file during the release phase in VSTS depending on which environment the solution is being deployed too. I am a complete beginner to this.
I've looked at variables but I'm not clear on whether this will solve this particular problem.
There are many tasks that can update the file during the release, such as RegexReplace Build task (As rickjerrity mentioned), Replace Tokens etc…, you also can do it programming (e.g. PowerShell) during release.
Steps:
Add the environments with same name for each environment (Set Scope)
Using that variable in task.
I have a Service Fabric project set up with CD in VSTS. The CD process have been set up from the CD wizard in visual studio. So far so good but when the release is made I'm not getting any value from the pre-defined variable called Build.DefinitionName that I use for naming the releases.
This is how my Release name is configured: $(Build.DefinitionName)-$(date:yyyyMM).$(rev:r)
If we look in the release log there is no value for the variables:
[BUILD_DEFINITIONNAME] --> []
[RELEASE_ARTIFACTS_{Primary artifact alias}*_DEFINITIONNAME] --> []
*This value is populated correctly.
And according to the docs of primary artifact variables the two variables above should be the same.
As a result of this my releases are named $(Build.DefinitionName)-201702.7
If I use Build.BuildNumber instead. I get the correct value.
How can I get the variables populated?
Update
When creating the Build and Release definitions manually the $(Build.DefinitionName) gets populated correctly on the Release side. But the problem seems to appear when you use the CD wizard from Visual Studio. I might be missing something but the settings of the Build Definition are identical. Or there is some funky stuff going on with the CD wizard.
The solution is to create the release definition manually on web access and set Continuous Deployment.
On the build number is passed from Build to a release, there is no out of the box way to pass more variables between build and release.
However I write a ser of build tasks to do this: https://marketplace.visualstudio.com/items?itemName=nkdagility.variablehydration
It consists of two tasks, the first saves the specified variables to a json file, which you should put in the build output.
The second restores the variables you want. Especially useful if you have multiple source build for your release.
We want to use TFS 2015.3 Release Management for Packaging/Deploying our Software.
For one of our Release Tasks we need access to the Release Artifact Variables in one of our Powershell Scripts.
But everytime we try to access one of those variables RELEASE_ARTIFACTS_[source-alias]_BUILDNUMBER for example, we receive the following error message:
[error] The term 'Release_Artifacts_[source-alias]_BUILDNUMBER' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I've already tried to print out all available Environment Variables by using an inline powershell script with the following statement: Get-ChildItem Env:.
But those variables weren't there anyway..
Are there any known issues when using Release Artifact variables?
It seems that the Release Artifacts variables are not available for TFS on-prem; I tested the same script with VSTS and with TFS2015.3.
In VSTS release you can see the release variables in the Initialize step while in on-prem release these variables are missing:
You are using the pre-defined variables of the form with Release Management Artifacts:
RELEASE_ARTIFACTS_[source-alias]_[variable-name]
You need to replace [source-alias] with the name of the alias for the artifact source included in the release definition. You can find the alias name in the Artifacts tab of a release definition.
Then you could use it as below：
When used in an Inline Script parameter, periods in artifact
names must be replaced with an underscore.
env:RELEASE_ARTIFACTS_[ScrumProject]_[BUILDNUMBER]
Artifact variables can also be passed as Arguments to tasks. In
this case, replace the underscore with a period:
Release.Artifacts.[source-alias].[variable-name]
More details please refer this tutorial page from MSDN: Artifacts in Microsoft Release Management
After some test, got the same result as ds19. Seems release artifacts is not support for TFS2015 update3 only work with VSTS for now.
Update
You just need to specify build.artifactstagingdirectory in Publish Build Artifacts or Copy and Publish Build Artifacts step, TFS will do the thing for you. To zip the artifacts you can also use a powershell script to achieve this, more detail info you can refer this blog Manage Artifacts with TFS Build vNext