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
Related
I have a DACPAC deployment task which is failing, because for some reason the value of the $(Build.ArtifactStagingDirectory) pipeline variable is changing between the build pipeline and the release pipeline. In the build pipeline, the variable is set to C:\agent\_work\2\a, but in the release pipeline it's C:\agent\_work\r2\a. This is causing the release pipeline to fail when it tries to deploy the DACPAC artifact, because the folder it's looking in is empty; the folder where the artifact actually is is ignored. How do I make these variables consistent between the build and release pipelines so that the artifact is retrieved from the same folder it's generated in? These variables appear to be built in, so I don't see any way to change them. I could always hardcode a path, but that seems a bit kludgy...
In releases you have System.ArtifactsDirectory which is
The directory to which artifacts are downloaded during deployment of a release. The directory is cleared before every deployment if it requires artifacts to be downloaded to the agent. Same as Agent.ReleaseDirectory and System.DefaultWorkingDirectory.
Example: C:\agent_work\r1\a
and in pipelines/builds Build.ArtifactStagingDirectory
The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: c:\agent_work\1\a
A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks.
Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself.
See Artifacts in Azure Pipelines.
This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
This is in line with your experience. And you cannot change it, as they are predefined. But can you clarify why this is a problem for you?
In the release pipeline, you can't directly access the files in the build pipeline, not only because the working directory is different, but also because they do not use the same agent. You need to download the artifacts first, and then use them in the release pipeline.
You can use the following ways to download artifacts:
Use the Download Build Artifacts task.
Go to the edit release pipeline page -> Select Add artifact -> Select Build -> Fill in the information related to the build pipeline (Notice the value of Source alias)-> Add it. You will find your artifacts are downloaded in $(System.ArtifactsDirectory)/${Source alias}
For more information about consuming artifacts in release pipelines, you can click this document.
Oh, I think I figured it out. Each release pipeline stage has an option called "Artifact download" which lets you specify which artifacts out of all those linked in the pipeline are actually used by that stage. I needed to check the appropriate checkboxes there in order to use the artifacts in the stage's tasks.
I can successfully build my project on local. When I do via VSTS then build is not successful. I get an error message that a dll cannot be found in my sub project. And it is Rapportage.Logic. The missing dll is used by Rapportage.Logic
Does anyone know the reason?
Most of the time this type of error comes down to:
files present/edited on developer machine but not commited (usually the .csproj file)
subtle differences between Visual Studio build and MSBuild.
I would try the following:
copy the MSBuild command from Azure DevOps logs (the line containing MSBuild.exe)
change the paths in the command to match your dev environment (e.g d:\a\1\s to c:\code\myproject)
run this command
If this command fails with the same error as the build you the problem is a difference between MSbuild and Visaul Studio.
If it succeeds, you most likely have missed a commit.
Build is successful on my local but not on vsts azure DevOps
It depends on how you add ReportViewer references.
If you add the ReportViewer reference manually, you need add the ReportViewer reference to the solution/project folder, then add the reference from that folder. In this case, the path of references are not hard-coded paths. Besides, you need add those/this ReportViewer reference to the source control and submit to the Azure devops repos.
If you add the ReportViewer reference by nuget, you need add the nuget restore task to restore those nuget packages. I could see you are using nuget restore task from your build log (The second image.), but on the build definition, I did not see you have add that task (The 3rd, 4th images.). So, make sure you have restore those packages when you build on the Azure devops, and you could check the restore task if those nuget packages are restored.
Hope this helps.
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.
In a custom vsts build task I want to know the path to the current build pipeline so that I can reuse the path to automatically calculate the path to the build drop folder.
In the vsts build portal where I create build pipelines they can be organized into folders. It's this folder path that I need to use in the build task. I can get hold of the name of the build pipeline from variables here: https://learn.microsoft.com/en-us/vsts/pipelines/build/variables?view=vsts&tabs=batch
But, there's no variable for the folder name. How can I get the folder name?
The folder that the build definition lives under is purely a build definition thing -- it has no bearing on a running build, so it's not populated as a build-time variable.
You can retrieve the build definition by making a REST API call:
GET https://{accountName}.visualstudio.com/{project}/_apis/build/definitions/{definitionId}?api-version=4.1. The account URI and build definition ID are available in a running build, and you can easily allow your script access to an OAuth token (populated in the SYSTEM_ACCESSTOKEN environment variable) for authentication purposes.
This will return a JSON object, which contains a path property. That's the path to your build definition.
You must be using an agent for your build pipeline. The agent may be hosted on VSTS or it may be on your premises.
Now, all the tasks in build definitions are executed on agent. Agent is simply a machine. Normally it uses below folders during build process.
Build.Repository.LocalPath or Build.SourcesDirectory or
System.DefaultWorkingDirectory = c:\agent_work\1\s : The local path
on the agent where your source code files are downloaded
Build.ArtifactStagingDirectory or Build.StagingDirectory =
c:\agent_work\1\a: The local path on the agent where any artifacts
are copied to before being pushed to their destination.
So answer your question:
c:\agent_work\1\s here source code is downloaded.
c:\agent_work\1\a here you can copy anything. Build definition uses this path to generate build artifacts at the end of build.
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