I'm wondering if it's possible to add a new field in the deployment screen for Bamboo. For example, I would like to add a field called "Release Notes" that I can use as a bamboo variable and replace in a custom NuGet package.
There is no way that I know of in Bamboo, but one of the benefits of using Bamboo is its integration with the rest of the Atlasssian suite! Linking release notes in Confluence or tickets in Jira to a specific deployment/build or in Bamboo is easy and incredibly robust.
Related
We have JIRA, BitBucket and Bamboo, all integrated running locally on a server.
I would like to have Bamboo build my software when I decide to release it in JIRA.
There is a document available at Atlassian that describes this:
https://confluence.atlassian.com/jirasoftwarecloud/running-a-bamboo-build-when-releasing-a-version-764478184.html
The problem is that my interface doesn't have the Build Variables as described in the documentation. This is crucial, because I want JIRA to pass the version number and Bamboo to use that as a variable for different tasks.
Here is a screenshot of the interface:
I realise that the docs are for JIRA cloud, but seeing that the same interface is available on the server edition, I would expect to be able to accomplish the same thing.
We use JIRA version 7.9.2 and Bamboo version 6.5.1
Does anyone know why the Build Variables might be missing, or how else to tackle passing variables from JIRA to Bamboo in a self-hosted situation?
I worked around this by using the "Dump variables to log" job to check what variables are available. As it turns out the JIRA version is available when a build is triggered through the JIRA "release" button.
The variable I could use is bamboo.jira.version.
This doesn't solve the actual problem of defining arbitrary variables in JIRA and passing them on to Bamboo, but it solves the problem in my use-case, as I was looking to pass the release version.
Update:
I have an offical answer form Atlassian regarding this question.
I was under the impression that the custom variables you want to pass are defined on the release screen in JIRA itself.
As it turns out, variables are defined on the plan or global level in Bamboo, and they can then be used/overridden on the release screen in JIRA.
It works now!
Currently we are using axion-release-plugin to control our release process. Now we would like to drop the SNAPSHOT and introduce the build number in our release process. So that we can achieve CI.
Basically currently we are using version 1.0.0-SNAPSHOT and now we need something like 1.0.0-BUILDNUMBER or 1.0.BUILDNUMBER from Jenkins.
Please provide any solution or plugin we can use with gradle.
I'm actually quite happy with nebula-release-plugin developed by NetFlix. It can generate a unique version number based on branches and tags in your git repo.
By default it counts with using git flow, but you can reconfigure the behaviour. Take a look :)
We are planning to use one testcase management tool for our project.
I am using testlink in my previous project.
But my management want JIRA as all our sprint planning and bug tracking is happing over there.
Can I export Testlink testcases and reports in JIRA without using any add-ion
If no, Then what are other option I can use.
I have find Zephyr add-ion which can do similer like this. is it any other option present?
I have also found that JIRA can accept rest-api but then I need to make changes in testlink project so testlink can send JSON to JIRA
What should I follow. any suggestion will help
I worked with one QA team that created a custom 'testcase' issue type in JIRA. They removed all the standard JIRA fields that weren't required and added in custom fields for things that were not covered by standard JIRA fields (such as 'test category', 'pass/fail' checkbox, etc.).
The 'testcase' issues were used as sub-tasks for user stories. Using this approach each requirement had one or more test cases associated with it.
When they needed to report they would do an issue search for issues of type 'testcase' within a particular time period. Then they would export all fields to Excel.
In my company we're using Testlink and JIRA and has been proposed to remove Testlink migrating all the data to JIRA but depending of the usage of JIRA(amount of data it is managing) as this can overload JIRA due to you will need several custom fields, maybe customized with JavaScript and that can be worth.
We analysed the possibility to use the Zephyr plugin which is appropiated for this usage.
In Jenkins, I want to create a job with two parameters. The first one gives a choice of environments (like DEV, TEST, PROD). Once the environment is selected I want the second parameter to show the list of servers from the selected environment. So the user can select ALL or a particular server to install. Is it possible to do this in Jenkins or any of its plugins? Basically I want the second choice box to be updated when the first choice box is selected.
This is not possible using the default parameterized build option in Jenkins. There may be another plugin written that does this (there are many many community contributed plugins) but I'm not aware of one.
However I have written several custom Jenkins plugins to essentially customize the build page UI for needs that are specific to my company. Writing a Jenkins plugin seems intimidating at first, but it actually isn't too hard if you know Java and Maven. If you don't know either of those, then you will need to find someone who does. https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial
Here is a similar question with a similar answer: Hudson or Jenkins Parameterized Builds using dynamic choices
I don't think that much dynamic choice parameters are available through plugins also. But you can try out this plugin to get what you want. Extended Choice Parameter Plugin to achieve what you want. But not exactly you want. Hope this helps.
I am preparing to move my team's source control from VSS over to TFS 2008.
This is for an asp.net website, and I am currently using a combination of nant scripts and Cruise Control to do all of the builds and deployments.
I've been trying to wrap my head around the best way to architect TFS build to do the same thing I'm doing with NANT and Cruise Control, but I can't determine the best approach.
Here are my requirements:
When code reaches a certain point, I manually apply a label to it.
This labeled code needs to be built and deployed to any of our 25 different Dev, QA, or production environments.
Any of these 25 environments can be on any current or past labeled version of the application.
I need to be able to deploy any labeled version of the application to any of the environments.
I'm currently accomplishing the above using NANT to perform the build, and using Cruise Control to just pass in command line options for which environment(s) to build and deploy. I have a Nant config file with a list of all of my environments, and an associated label each environment should currently be using. This file gets manually updated whenever a new label is created.
I know the approach I'm using for NANT probably won't be the same as with Team Build, but has anyone done something similar with Team Build and could share how you accomplished it?
Labeling in TFS is much more robust than in VSS. When you create a label, you can create based on a changeset, date, workspace version, heck even a different label. (BTW, I was grabbing a link and came across this post that you might find relevant.)
By default, a Team Build will build from the latest version of code in source, but you can override the "CoreGet" target in a build to build a specific version. Aaron Hallberg (a.k.a. TFS's John Skeet) shows an example here.
see 4.
I haven't personally had this difficult of a requirement, but I've done something similar. When you queue the build, you can pass in any number of parameters in a couple important ways, 1) through the response file and 2) at queue time (simple example here). In either case, two parameters could be which environment and which label/version number. At my current project, I have continuous integration turned on, so when code in a workspace is checked in, the current code is automatically labeled, pull the specifics for my drop location from the response file, then deploy to the respective location.
Given the fact that you have ~25 environments and n number of versions/labels, you could build a simple GUI that reads the current labels through the TFS API and lets you pick which version to build to a particular environment.
To answer the question, the way I addressed this was to use a combination of a custom build task, cruise control, and msbuild.
The custom build task allowed me to get the latest version from a specific branch and label.
Cruise control allowed me to pass in specific information for a specific build to MSbuild, using a config file, but initiate the build from a UI.
msbuild was used like normal, however it was called from cruise control, and the custom build task did most of the work.