How to Change Release Name format in tfs release dashboard? - tfs

Is there any way to change the Release name of Pipeline after it started and dash board will still consider the new name and reflect it ?
For example at the start of the build ReleaseName=release_1 and after that in one of the step we change its value to ReleaseName=release_11.04122018 but release dashboard will still be having older ReleaseName, how can it be updated with changed name ?

To customize the build and release names, you could consider using the commands of build.updatebuildnumber and respectively release.updatereleasename from a PowerShell script. See also this page on GitHub.
Translated to yaml, it'll look like this:
- powershell: |
[string]$version="$(Build.Repository.Name)_SomeCustomData_$(Build.BuildId)"
Write-Output "##vso[build.updatebuildnumber]$version"
displayName: Set Build Number
Same applies for setting a release number, but since it's not possible yet to use yaml for release pipelines, you'd need to add a PowerShell task yourself and add an inline script like this:
[string]$name="My custom release name"
Write-Output "##vso[release.updatereleasename]$name"
To see which variables you can use for build and release pipelines, check these pages:
Build variables
Release variables

Related

Jenkins pipeline to change appssettings.json file and build according to the environment

I had a requirment to build a console application, but i need to change some values in appssettings.json file according to the environment and then build it. I am new to jenkins and want to know how to acheive this.
for dev change values in json file and build it -> for test again change the json values and build it -> till prod
This can be done in multiple ways for example (the common idea between these is to check the incoming branch):
You might find better ways to do it but you can use this as a start.
Using bash, jq, sponge through sh step:
Create a json file as a template like the following (consider keeping this file in a version control to clone every build)
# settings.json
{
environment: 'ENVIRONMENT_NAME',
appVersion: 'APP_VERSION'
}
Check the branch name value through if condition and update the template according to the branch value
jq '.environment = "branch_name"' settings.json|sponge settings.json
Use the customized settings.json in your application's code
Using Config File Provider Plugin which can be used inside the Jenkins pipeline as the following (also update it based on the branch name)
configFileProvider([configFile(fileId: 'FILE_ID', targetLocation: 'FILE_LOCATION')]) {}
Check if the application framework can make use of environment variables.

Set Jenkins build name only on successful build

I am trying to set the build name of a Jenkins build only on a successful build. Any failure, whether in building or testing, should use the 'default' (build number) instead.
I can't find any mention of this in the documentation or online. Is this possible?
It is pretty simple to do with Groovy Postbuild: https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin
You have some nice examples there too. So just check result and then set the:
manager.build.result
As they do in Example 3
In the post build operation you can run a "set of scripts" - there you can select any way to do so, set a description, run system groovy or groovy script to change the name or any other method of your choosing - you can add many build steps to help you do so. wrap it around a conditional statement and run it only when build is successful.
Good luck!

Jenkins - pass build name to code being built

I have my Jenkins job defined to use a timestamp for the build name. I'd also like to be able to use that build name in the code being built. For example, suppose my application prints a "startup" message during initialization. Ideally, I would be able to somehow inject the build name into this startup message.
Example:
Application XYZ, build 20160503-0420, is starting up...
I'm curious what sort of techniques folks have come up with to do something like this.
Thanks!
Well, at first insert build number directly into your code it`s very bad practice.
We create debian package by Jenkins. Debian packages contains control file, some kind of description of package, version, dependency, etc.
In our repo control file contains
Section: misc
Priority: optional
Package: #packagename
Version: 0.1.0+#build~#repo
As you see we keep fixed only major version of software
Then we create package we replace texts started by # with build variables
sed -i 's/#build/$(BUILD_NUMBER)/' $(FAKEROOT)/DEBIAN/control
sed -i 's/#repo/$(REPONAME)/' $(FAKEROOT)/DEBIAN/control
sed -i 's/#packagename/$(PROJECTNAME)/' $(FAKEROOT)/DEBIAN/control
And after that we publish, deploy, send email, doing all Jenkins magic.
I think you can build binary and distribute it
Of course if you want to add this changes into you repository you can use Git publisher, or another source management systems, but tell you again this is bad practice.
We use powershell plugin in Jenkins and this is how we write our job ...
Write-Host Build id $env:BUILD_NUMBER started at Get-Date
For more build parameters refer to below URL
https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-JenkinsSetEnvironmentVariables

Getting CFBundleVersion from within Jenkins to use it as a variable, something like ${APP_VERSION}

What I'd like to do is to be able to add a tag to commits which Jenkins is building from. Right now I tag commits with the Jenkins build number but I want to also add in the app version as listed in the Info.plist CFBundleVersion in front of that.
What I want to know is, how I can grab that value using Jenkins or otherwise and be able to use that as a parameter/variable within Jenkins?
I've seen references to using plistbuddy to set this value so I would assume there's a way to use that to get the same value. Though how and how to get that to where I can use it in Jenkins I don't know.
For further clarification I am using Git Publisher in Jenkins to create a tag and push it with this format
jenkinsbuild-$BUILD_NUMBER
This results in a tag on the commit in git like this - jenkinsbuild-303
What I want, assuming my app is currently at version 3.5 is a tag that reads - jenkinsbuild-3.5-303
I managed to piece together a solution from the answer which #agy linked to. Here's what I did:
In the Build section for the Jenkins configuration, I added the following two lines to an 'Execute Shell' step after the Xcode step:
APP_VERSION=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "path to your plist")
echo APP_VERSION=$APP_VERSION > appversion.properties;
After that, I added an 'Inject Environment Variables' step (I think this is part of the EnvInject plugin), to which I added "appversion.properties" to the Properties File Path field.
After this is done, APP_VERSION is now available as an environment variable in subsequent shell command steps.

Jenkins job for remote deployment - multiple environments

I'm trying to create a generic Jenkins job for deploying different projects from different GIT repos and branches to different application servers (in any combination).
I have 2 string build parameters for the repo and for the branch, and a small shell script in a pre-build step which based on the build params creates a deploy.properties file with properties URL and PROFILE.
Another pre-build step is the Inject environment variables which uses the deploy.properties file previously created.
I'm to use the URL property in the Jenkins Deploy Plugin in the following way: Tomcat URL field - $URL.
Also, in the build section, I'm using the PROFILE property: clean install -P$PROFILE .
The problem is that the placeholders or not replaced by the values I've set in the shell script. Not that is I do another post-build action and I'm echoing the same placeholders, the values are replaced and it seems to work. Other check I've done is the Environment Variables section from a given Build and the variable values are there, so the injection works.
Any ideas?
Try the below and make sure you don't have the cmd in single quotes or anything.
clean install -P${PROFILE}

Resources