I am using the TFS2018 api and I would like to store a template name as part of the BuildDefinition.cs object because I need to know what template the build definition is based on. Can I use the tag property for this or is there a recommended way to store custom information as part of the BuildDefinition?
Tag is not supported in build definition.
However you can store the custom information (Template info here) as comments when you save the Build Definition first time. Then you can check the info from history (Select specific build definiton > Edit > History)
You can also add the information as comments via REST API (Update a build definition)
Alternatively you can add the template info within the build definition name.
Related
Is there any way in Jenkins where I can view customized data for a specific project. Like in the screenshot we can see columns (Salves, Online slaves, offline slaves etc.) Screen shot Example
View> Edit View> Portlets in the right column > Slaves statistics
I want to customize these columns for my project requirements like Build numbers, Revision numbers, svn changes (for every individual revision), the user (who submit this build) and Status. I knew we can see these changes individually from localhost:8080/jenkins/job/Job_name/224/ but I want to see whole information in one single form. I am good in Powershell but Java is not my cup of tea. Please help.
I don't think there is a plugin available to add custom columns, will require creating a custom plugin yourself. A plugin to add some pre-defined extra columns is available https://wiki.jenkins.io/display/JENKINS/Extra+Columns+Plugin
Alternatively, we added custom key value pairs in every build using currentBuild.description as shown here to be able to view in a single screen artifact name and environment for each build
I am trying to figure out if there is a difference between the two pre-defined variables in TFS Online 2017: $(Build.Repository.LocalPath) and $(Build.SourcesDirectory). I have a build that uses these two variables and didn't know if I could use them interchangeably or not.
Looking at Microsoft's documentation the descriptions are as follows:
$(Build.SourcesDirectory): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
$(Build.Repository.LocalPath): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
Are these representing the same thing or am I missing something?
They're synonyms. Most standard templates and tasks use the $(Build.SourcesDirectory), so that is what I tend to use.
They often result in the same but not necessarily. As described in the docs:
If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable):
The description for Build.SourcesDirectory on the same page contains a similar note.
Basically if you want to define a custom path for the self checkout and still not need to specify the extra dir, you specifically need Build.Repository.LocalPath.
For clarity, you can still use Build.SourcesDirectory to resolve to the full path if you have the usual
- checkout: self
path: s
and I'd recommend using it whenever possible if so. If you have something like
- checkout: self
path: main_project
then you'd need $(Agent.BuildDirectory)/main_project to reach the same.
I am trying to link or associate an external application url to jenkins job build.
So for every builds, this link or url should be available at the left side and any user can simply click on it to launch the external application.
So far I explored the following plugins for this:
https://wiki.jenkins.io/display/JENKINS/Associated+Files+Plugin - this associates a file or directory to the build , something similar to the html publisher plugin... not a url
https://wiki.jenkins.io/display/JENKINS/DocLinks+Plugin - similar to above , associate a doc from the build artifact directories
https://wiki.jenkins.io/pages/viewpage.action?pageId=52298023 - this Side bar link plugin can associate a external link to the jenkin project, but not to every builds
for me the external link which I am trying to associate to the build , dynamically changes for each build , basically some of the query parameter in the external link, so it's critical to associate it to every builds for tracking and other purposes . ex: the external link will be a like a small web app
http:hostnamexxx:port/somepage?para1=xxx¶2=yyyy
Please let me know if there is any plugin for this specific purpose or any other ideas
This would be the Anchor Chain plugin. I've played around with it a bit:
The docs state that the icon can be omitted. Then however you need to insert a tab character after the URL.
When inserting a link to an icon, it is always relative to Jenkins base URL.
I am calling a console application from within a TFS build process template (copied of DefaultTemplate.xaml). I would like to pass a the unique "Request ID" to the app. I cannot find an argument or parameter in the XAML with this value. Nor can I find much documentation on the "Request ID", however I know one must exist based on the Build history. The build history "View Summary" tab shows a request ID (ex: "Request 12345").
How can I get this value within the template (xaml)
Edit: In the TFS Database (tfs_defaultcollection), I believe this is tbl_Build.BuildID
Its a string but it looks like BuildNumberFormat is available via the build process. I also see BuildDetail.BuildNumber.
I was able to get the TFS Request ID through a collection on the BuildDetail object: BuildDetail.RequestIds.Item(0). This is a collection so I need to verify it has values and that Item(0) is not null.
I am not certain why RequestIds is a collection? I assume theoretically you can have more requests associated with a build? Not necessarily clear, but certainly consistent with the TFS build process.
So I need a job parameter to contain the next build number as its default value. This is mostly for information purposes to the user, so could go into the job description instead.
I've taken a look at dynamic parameters, to little avail.
Obviously, environment variables like BUILD_NUMBER are not set until the job has started building.
This is a stand alone job.
Edit:
The purpose of this parameter is just to provide information to the user who is kicking off the job. The parameter will contain a path to a directory that will be created during the job execution. The name of that dir will contain the build number that created it. /Testing/myTest_job$BUILD_NUMBER
If you want to have a generic description, you can user the Description Setter Plugin.
Install the plugin
Add Build Step "Set build description" as first Build Step
Set "Description" to /Testing/myTest_job${BUILD_NUMBER} and leave "Regular expression" blank
Alternative:
I would suggest to use the post build step "archive artefacts". This will provide the files your job creates as i.e. download link:
http://jenkins.foo.bar/job/example/lastSuccessfulBuild/artifact/yourfile.exe