Atlassian Team members are employees working across the company in a wide variety of roles.
March 27, 2020 edited
@mark_gillespie as @Marcin Gardias wrote 'UPM 3.0.6 is incompatible with Bamboo 7', so the upgrade report is not wrong. However, a compatible version of UPM is bundled with 7.0 release, so if you upgrade you will get a new working UPM plugin.
Atlassian Team members are employees working across the company in a wide variety of roles.
March 27, 2020 edited
@Cory Francis well, changing the header color may not seem as an important feature to you but it was important for 182 Bamboo customers who voted for it (https://jira.atlassian.com/browse/BAM-13311). It was prioritized as one of our top-voted issues. Is declaring plans with Terraform a highly voted issue? Was it even raised as an issue? Because if it wasn't the existing highly popular issues will get prioritized over it.
@Martyna WojtasBAM-14013 and BAM-15155 have 235 votes between them for essentially the same feature request. My math says that's more than 182. So, when can we expect it to be prioritized?
@Marcin Gardias is it possible to turn this "enhanced" mode on for some plans, and off for others? We have some plans that should only be run on master and support branches, and others that should be used also for developer branches. Or should we do that conditionally in `PlanSpec` based on the name of the current checked our branch or something?
Also, if the `bamboo_specs` folder is changed on the branch, will that change the plan for that branch?
Lastly, have the issues with AdoptOpenJDK 11 OpenJ9 been resolved? This is the only JDK our IT runs, and at the moment executing specs using JVM this fails, at least in our environment. I have a different open issue for that…
I'm not sure which exact case you have in mind, so I'll try to answer both:
Case 1. A plan needs to be run on certain branches only: This is still controlled by Automatic Branch Management options. Adding plan specs to a branch does not _create_ a Plan Branch. The specs only define _how_ the plan branch is configured in Bamboo not _if it exists_. So you still have full control over which branches are built and which are not.
So in your example, you can configure your first plan to only create branches for specific name patters or only for pull requests or even turn off automatic creation altogether and only create branches by hand. Then, the plan branches thus created will be configured according to specs stored on corresponding VCS branch.
Case 2: You want a number of branches to be built but only some of them need separate (a.k.a divergent) configuration. This can be achieved by removing corresponding specs from on the vcs branch. If specs for a plan are missing on VCS branch, Bamboo reverts to pre-7.0 behaviour and configuration of a plan branch is inherited from master. In Java specs there's a conditional construct that makes it easier: https://docs.atlassian.com/bamboo-specs-docs/7.0.2/specs.html?java#conditional-execution-of-specs-on-branches, in YML you need to actually remove the specs*
If bamboo_specs folder is changed on a branch, corresponding plan branches are updated. However you cannot add a new plan or modify deployment configuration this way: that has still to be done from master branch.
Also, as I said before, the branch specs are only applied to _existing_ plan branches.
I'm sorry but JDK11 is not yet supported, we only test Bamboo with JDK 8 (that includes OpenJDK8)
*) for now, we consider adding such branch-dependent constructs to YML Specs too
Atlassian Team members are employees working across the company in a wide variety of roles.
April 1, 2020 edited
@James Brown "Does anyone know if it’s possible to store a python test file in a directory and then in an automated fashion parse it out into jobs/tasks in a bamboo build? I would like to make it easier on developers to write there TDD write in the same branch they are working on vs in a bamboo spec repository. This would cut out time of forcing them/hand holding them through creating/updating a build plan through the UI and they would not have to learn java specs."
It's not possible for Python. However, you can have specs in the same repository/branch as code. Also, you can use YAML specs instead of Java.
Great that you are taking on feature considerations. But are you also sometimes reconsidering bugs which are not at all feature considerations, like e.g. https://jira.atlassian.com/browse/BAM-4213 ? That one is open since 2009.
@Marcin Gardias, you are making me giddy with excitement! We basically want case 1. That way we can also _test_ our plans before they get to master… which is game changing! The only downside is that it won't let us create a new plan to test, but I guess we can work around that by creating a dummy "do nothing" plan for master, and then doing the actual dev/testing work on the branch.
I just double checked, our server _is_ using Java 8, however building plans still fails (BSP-45848). Our JDK is:
@Marcin Gardias, you are making me giddy with excitement! We basically want case 1. That way we can also _test_ our plans before they get to master… which is game changing! The only downside is that it won't let us create a new plan to test, but I guess we can work around that by creating a dummy "do nothing" plan for master, and then doing the actual dev/testing work on the branc
I just double checked, our server _is_ using Java 8, however building plans still fails (BSP-45848). Our JDK info is:
Atlassian Team members are employees working across the company in a wide variety of roles.
April 1, 2020 edited
@Graham Ballantyne if we wanted our prioritization process to be just a function of jira issue parameters we would let an algorithm do it for us :) These 2 issues describe slightly different needs, however we can try to consolidate them into a single feature. Thanks for flagging! As they are aligned with our current strategy we are moving them to the short term backlog.
Is Project/Plan specific variables supported vs only Global Variables as was the case with previous versions of Bamboo? This would be an amazing feature to have as each build plan that runs, runs all Global Variables.
@Martyna Wojtas, I have been looking into using these branched specs, however this is tricky on our test server as we don't have the capability of our production server… however a couple of questions:
Where is the documentation for this?
Our Bamboo-specs have been updated over the years, do we need to go back to all old branches and update them to be the same as current master? Or what is the trigger to determine if it "uses master build configuration" or not?
In short: Specs for branches can be used under the following conditions:
the specs repository is in Bitbucket Server and configured in Bamboo as Bitbucket Server repository type (i.e. plain git won't work)
so called 'default' repository of a plan is the specs repository
exception to the rules above: in order to avoid unexpected re-configuration, plan branches created before 7.0 are not configured by specs. You can enable Specs for those branches in Branch Details tab.
In any other case: plan branches work as they used to work in version 6.
@Martyna WojtasImprovements to branch configurations are not working, I have upgraded to 7.0.3 it looks the same as old , am unable to create a separate plan for branches
Atlassian Team members are employees working across the company in a wide variety of roles.
May 18, 2020 edited
@Manjunatha NS I'm sorry to hear that! For the specs for branches to work the above-mentioned conditions need to be met:
the specs repository is in Bitbucket Server and configured in Bamboo as Bitbucket Server repository type (i.e. plain git won't work)
so called 'default' repository of a plan is the specs repository
exception to the rules above: in order to avoid unexpected re-configuration, plan branches created before 7.0 are not configured by specs. You can enable Specs for those branches in Branch Details tab.
Atlassian Team members are employees working across the company in a wide variety of roles.
May 18, 2020 edited
@ksondere Yes, Bamboo is getting a renewed focus :) Forthe rest of Q4 FY20 we are focusing on developer productivity, mainly on improving logs and specs for branches experience. We are currently finalizing the strategy for FY21.
@Martyna Wojtas Can you please, _please_! add support for continuing existing jobs on builders? We have a number of long running jobs (multiple hours) and if the bamboo server needs to be restarted for any reason, which seems to happen fairly often for us, then all of the builders lose track of the jobs that they were running, and start running a new set of jobs.
This has three problems for us:
We get spurious failures in our builds, since the job completed, but shows as failed in bamboo, since it goes to unknown status.
If the job has already been running for multiple hours, we end up wasting a lot of time restarting the job to do what has already been done.
Our builders are sized to run 1 "task", when they run two concurrently, one of them will fail and be killed by the OOM Killer. It seems that this often happens to the new task, not the old one, where we then get back to points 1 and 2 _again_.
@Martyna Wojtas: when is support for divergent branches for Bitbucket Cloud landing? Is seems very weird to release such an important feature only for a subset of Atlassian's own code hosting solutions.
53 comments