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!
Related
I have a significant amount of pre-configuration that I want to automate for Jenkins. E.g. Pre configuring gerrit for the gerrit trigger plugins, pre configuring saml, libraries etc
I'm aware of two methods typically used to do similar tasks:
Configuration as code plugin + yaml configuration
Groovy scripts to execute from the init.groovy.d directory of jenkins home on Jenkins startup
My users want to be able to update Jenkins configuration from the UI without needing to update yaml, suggesting the config as code plugin isn't fit for our purpose as I believe it reapplies the config when the Jenkins container is restarted.
My hunch is to use groovy scripts that remove themselves after the first execution so that they don't reapply themselves on restart.
Is there a more standard way of pre configuring Jenkins? or is groovy my best bet?
TL;DR: Use the file system
Why? There is no "standard" way to achieve what you intend; the two approaches that you suggest are viable options for sure.
From operational point of view, however, it will be good to select a solution which is
generic (so it can cover all aspects of Jenkins configuration) and
"simple" to use
Now,
"Configuration as code" makes you depend on the corresponding plugin -- it may or may not support a specific configuration option
With groovy, it is sometimes quite difficult to find out how to set a Jenkins configuration option (and how to store the setting permanently).
Since all Jenkins configuration data is stored on-disk, another option for bootstrapping Jenkins with a well-defined configuration is to pre-fill those configuration files with proper content right away:
You can be sure that this works in all cases, including all border cases (like, secret/encrypyted data)
Users can change the data later on as needed
Usually, it's quite easy to find the proper configuration file
On the downside, there is a risk that the configuration file format might change with newer versions of the core or of some plugin. However, a similar risk exists for the two other solutions that you suggested.
Tip: for rolling out such pre-configured Jenkins setups, it is helpful to disable the Jenkins setup wizard by setting jenkins.install.runSetupWizard to false.
When you combine words like : pre-configuring Jenkins, init.groovy.d, jenkins home, jenkins startup, etc, it sounds confusing o_O
When Jenkins is ready to use, usual folks just need to create jobs or pipelines. If you need to create a job or pipeline, you just need to install and configure some plugins. Very few of them need groovy, because the goal is "Easy to use".
Advanced user are able to create its own plugins, with java. But almost all is available as plugins.
You can use groovy in a pipeline scripts or declarative pipelines.
So if your question is more like "What is the best way to create and configure jobs or pipelines", I can advise you:
Try much as possible to use pipeline scripts or declarative pipelines.
Use just verified and supported plugins.
Stop call shell scripts in hard drive.
Stop using complicated configurations. Almost all of requirements are already implemented and documented.
If you have a requirement and no one plugin seems to help you, ask here in stackoverflow or develop your own plugin focused in configurability, so you can release it, for the benefit of Jenkins Community.
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.
Without switching over to Jenkins to do builds, is there (or will there be in the foreseeable future) a pipeline as code solution for TFS build?
EDIT: For clarity and future reference, I'm looking for a declarative method of defining a build, like appveyor or Travis or Jenkins do. Checkout the answer for the uservoice suggestion for this functionality.
There isn't any way to achieve this feature for now but we have already started working on this. Refer to this feature request on VSTS User Voice site for details: provide a way to version-control build definitions.
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 using Jenkins for a project and would like to know if the following is possible. I have four separate SVN modules which are checked out as part of the job. Each SVN module is added to a separate directory. Depending on which module is updated during the SCM polling, I would like to only build certain directories.
With Cruise Control, I was able to set a variable for each module that was updated and passed those variables to the ant build script to control the build.
Has anyone done anything similar or have any ideas?
Thanks,
Sean
This Question is pretty complex. You are touching too much different parts of CI builserver and some tasks out of it.
Basically ... providing job / project in Jenkins with information that controls behavior of build itself is not best way, but if you have no other option, well, then you have no other option.
Build itself should be enough agnostic and it should contain all the parameters enabling build to be successful both in CI, and in Workstation ( from cmd.exe, for example ).
Depending on which module is updated during the SCM polling, I would
like to only build certain directories.
So basically you want Maven build system, which provides model/module based conditional build, not building one single Project, like Ant does.
With Cruise Control, I was able to set a variable for each module that
was updated and passed those variables to the ant build script to
control the build.
Here you want to have some kind of similar Build Triggering capability. Here comes place where without more detailed explanation of requirements only thing I can suggest is to check out Pramatreized Build Trigger plugin, which would allow to trigger build by parameters you set.
Has anyone done anything similar or have any ideas?
Finally, here you can also check out this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
In the conclusion, some features are provided by Jenkins out-of-the-box, so if you use Ant, you can easily use Environment variables and start building your needed behavior. Usually after investing some time by thinking how to do something without help from tons of Jenkins plugins it somehow makes you really understand, what is the key of thing you want to achieve.
Hope I helped somewhat. Cheers, mate.