Im getting this error on Team Services release. I suspected that this error occours because im generating a zipped artifact.
The MSBuild configuration:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"
Then in my Release im trying to replace the appsettings.json variables:
So the artifact is a zip file and problably because this the release management is not finding the appsettings.json file. But what is the way to deal with it? Build an artifact not zipped?
This worked for me:
**/appsettings.json
The json file is buried down in a long deep path based on the location of the agent and how MSBuild packages it up...it's not at the "root".
For example, my json file was in this folder within the WebApp.zip file:
WebApp.zip\Content\C_C\Build\Agent\agent_work\3\s\CrmsAngularPOC\obj\Release\netcoreapp1.1\PubTmp\Out
if your source folder is $(System.DefaultWorkingDirectory)/_SOURCE_FOLDER_/artifacts
you can use "appsettings.json"
but if your source folder is $(System.DefaultWorkingDirectory)/_SOURCE_FOLDER_
you can use "**/appsettings.json"
You should use JSONPath expressions to specify variable(s) you want to substitute for Json variable substitution option.
Detail usage of JSON variable substitution as below:
Provide new line separated list of JSON files to substitute the
variable values. Files names are to be provided relative to the root
folder. To substitute JSON variables that are nested or hierarchical,
specify them using JSONPath expressions.
For example, to replace the value of ‘ConnectionString’ in the
sample below, you need to define a variable as
‘Data.DefaultConnection.ConnectionString’ in the build/release
definition (or release definition’s environment).
{
"Data": {
"DefaultConnection": {
"ConnectionString": "Server=(localdb)\SQLEXPRESS;Database=MyDB;Trusted_Connection=True"
}
}
}
Variable Substitution is run after configuration transforms.
Note: Build/Release’s system definition variables are excluded in
substitution
Related
I have automated a build/deploy process in Azure Devops / TFS and would like to scrape a file or folder name as a variable from the source file path that is used for my build artifact.
For example, I might want to scrape the folder name of the folder at the build source path and store it for use in the build #, release #, etc.
I have gone through Microsoft's documentation and I believe the information I'm looking for might be associated with the following... but I can't seem to find the right location.
Release.Artifacts.{alias}.BuildURI #The URL for the build.
Azure pipelines example: vstfs://build-release/Build/130
GitHub example: https://github.com/fabrikam/asp
When I attempt to locate the folder name from the source, I have so far been unable to find it in code.
Sorry, it's not possible to get the source file & folder name/Artifact name from the environment variable.
As of now, you need to specify the Artifact alias name in order to access the artifact related information.
E.g, Release.Artifacts.{alias}.DefinitionName
General Artifact variables
Primary Artifact Variables
Using default variables, you can use the default variables in two ways - as parameters to tasks in a release pipeline or in your scripts. here
I've been asked to move some variable from a Groovy script out into a configuration file. I'm fine using something like :-
readFile('../xx-software.cfg').split('\n').each { fileName ->
sh "wget ${theURL}${fileName}"
}
However, even though I have added xx-software.cfg into the same directory as my Groovy script it does become available for use within that groovy script.
I hope this makes sense!?
How can I move my variables out into a config file to make it easier for the application support team to make future edits without changing the code?
There are a few approaches you could use.
Firstly, file format for the configuration and how to read the data into variables. You could use Java Properties format, YAML or JSON and these are all handled by the Pipeline Utility Steps plugin with steps here. You can read the file with these steps:
readProperties
readYaml
readJSON
Next problem, how to get the file available to your pipeline so it can be read from the workspace using these steps. Possibilities are:
In source control with your pipeline code. It can be fetched with the pipeline.
In a separate source control for configuration, your pipeline will need a step to fetch it.
Use the Jenkins Config File Provider plugin. It has a step to provide a config file managed in Jenkins.
Provide it as a Custom Tool zipped archive from a binary server like Artifactory. You can use custom tool definition pipeline steps to make this available to the pipeline.
The Config File Provider option might provide any easy way to have a file that can be updated, but there won't be any version control of it.
We have a version number which is retrieved from a file during the build and needs to be passed to the deployment script. What is the best way to do this in TFS 2017?
Right now, we are thinking of embedding this version number in the artifact file name and parsing it during deployment, which feels a bit clumsy.
BTW, is there a way to get the artifact file name easily? Looks like TFS already knows this as shown in the log below:
No path specified for search pattern: *.zip defaulting to: F:\TFS2017_Release_Agent\_work\r1\a
2017-12-08T16:38:36.8519067Z Searching for: *.zip under directory: F:\TFS2017_Release_Agent\_work\r1\a
2017-12-08T16:38:36.8519067Z Found: 1 files to extract:
2017-12-08T16:38:36.8519067Z F:\TFS2017_Release_Agent\_work\r1\a\ZFJ0_ServiceSearchPlusBuildDefn\BETALink.Service.SearchPlus\ZFJ0_BETALink10.4 DevOps_BETALink.Service.SearchPlus_1.0.0_886.zip
2017-12-08T16:38:36.8519067Z Creating destination folder: F:\TFS2017_Release_Agent\_work\r1\a\48
2017-12-08T16:38:36.8519067Z Extracting file: F:\TFS2017_Release_Agent\_work\r1\a\ZFJ0_ServiceSearchPlusBuildDefn\BETALink.Service.SearchPlus\ZFJ0_BETALink10.4 DevOps_BETALink.Service.SearchPlus_1.0.0_886.zip
2017-12-08T16:38:36.8519067Z [command]F:\TFS2017_Release_Agent\_work\_tasks\ExtractFiles_5e1e3830-fbfb-11e5-aab1-090c92bc4988\1.112.1\7zip\7z.exe x -oF:\TFS2017_Release_Agent\_work\r1\a\48 F:\TFS2017_Release_Agent\_work\r1\a\ZFJ0_ServiceSearchPlusBuildDefn\BETALink.Service.SearchPlus\ZFJ0_BETALink10.4 DevOps_BETALink.Service.SearchPlus_1.0.0_886.zip
2017-12-08T16:38:36.8987827Z
First, custom build variable couldn't be used directly in your release definition with TFS 2017.
There had also been a related user voice:
Project level build/release variables
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/14515326-project-level-build-release-variables#
As a workaround, you could use some 3-rd party extension such as Variable (de|re)Hydration Tasks that help you make use of your build variables in your Release workflows.
Variable Dehydration Task - During your build you can save the variables to a json file stored with your other build assets
Variable Rehydration Task - During your Release you can load the saved variables and gain access to them.
It does this by prefixes, so you can save/restore all default build variables that are prefixed with 'BUILD-', but if you prefix your own variables with i.e. 'ABC_' you can also save them from your build and restore them in your release.
Another way is do it through powershell scripts, how to please refer: TFS 2015 Release management access build variables
About build artifact name, there is not a related predefined system variable, it's just entered as an argument in Publish Build Artifacts task.
Im trying to make a CD enviroment with as ASP.NET Core (.Net Framework) using team services.
The build definition gerates a zipped artifact with the website.
Then in my Release configuration i would like to change some values of my appsettings.json properties, but the artifact is zipped, so apparently the release management has no access to the appsettings.json the logs says that Error: NO JSON file matched with specific pattern: appsettings.json, what is the correct way to do that?
I eventually run this task both for build and release successfully now. To troubleshooting the issue:
If your release was run on private agent, you should check in the drop folder to check if the artifacts are zipped.
In related build definition check if $(Build.ArtifactStagingDirectory) has zip file. If there has no zip file, you can add Archive Files task to to zip files in $(Build.ArtifactStagingDirectory).
If the appsettings.json is no in the root of zip folder, use **/appsettings.json for JSON variable substitution in Azure App Service Deploy task.
I am executing sonar through Jenkins build, there is use-case where 'src' location changes depending upon build so i want to use environment variable for specifying 'src' path.
For example in sonar-project.properties i want to specify as shown below:
src= c:/project/workspace instead i want to use src =${SONAR_RUN_WORKSPACE}
Environment variables are supported in sonar-project.properties starting from SonarQube Scanner version 2.9 (see SQSCANNER-9).
So, this should work now:
sonar.sources=${env.SONAR_RUN_WORKSPACE}
You cannot pass env variable into sonar-project.property file.
If you are creating sonar-project.property file from jenkins, you can use build with param.
(or)
Create a sonar-project.properties without sonar.source.
Create build with param variable {path}, get the src path from user for each build,
Map the variable with sonar.source=${path} in sh.
Append sonar.source to sonar-project.properties for each build in sh using (>>) or cmd from jenkins.
eg) sonar.source="path" >> sonar-project.properties
finally work space contains sonar-project.properties file with src path.
Nope, environment variables are not supported in sonar-project.properties. In any case, back to your use-case: you better use a relative path for sonar.sources so that, wherever analysis is ran (i.e. whatever workspace with Jenkins), sources are always found at the expected place (from the project's base directory).