Bamboo - export plans from one Bamboo instances, move them to another Bamboo instance? - bamboo

Is there a way to export plans from one Bamboo instances, move them to another Bamboo instance? I researched a little, looks they have no plan yet though a JIRA has been raised. I just want to confirm that this is the case, and at the moment there's no way you can export your plans from one Bamboo instance, and move them to another? Another scenario is back up the plans, if your running Bamboo instance corrupted, you can restore the plans from this backup.
https://community.atlassian.com/t5/Bamboo-questions/How-do-export-import-an-individual-plan-from-one-bamboo/qaq-p/803675
https://jira.atlassian.com/browse/BAM-19832?_ga=2.108167110.57756773.1550032807-1609212272.1542958766

Yesterday i researched the same thing and find out that it´s possible from bamboo 6.0 and forward with something called Bamboo Specs, you can find out more here: https://confluence.atlassian.com/bamboo/exporting-existing-plans-to-bamboo-specs-894743917.html

Related

How do I manually remove old release builds from an expired/deleted plan branch in Bamboo?

I use Bamboo regularly as a QA tester to deploy pull requests and feature branches/release branches, but I'm not a developer and have a layman's understanding of how it works.
Our Bamboo configuration is set up to remove inactive branches after a certain amount of time (2 weeks) which happens pretty regularly with longer-term projects, unfortunately. (When that happens, I do know how to configure a new plan and run a new build.) Often, with these larger projects, they've been deployed manually many times over the course of the project, resulting in a large list of possible "release" versions when I go to "Promote existing release to this environment."
Now, I have a brand-new build of a brand-new plan for a project I've been working on off and on for a year and I would like to delete all these old builds (releases?) that show up in the dropdown when I want to just deploy the current version of the current new build, but I can't figure out where to do it (neither can the devs I've asked, but it's NBD to them, whereas this is a constant annoyance for me).
All the advice I can find online says things like "all builds are automatically deleted when the branch expires ...." and that doesn't seem to be true, because these are definitely from old expired plan branches. They also explain how to delete things manually .... from an existing plan branch, which I don't have, because the older plan branches expired and were removed.
Am I using the wrong terminology here and these aren't "builds" and there's a separate way to delete them? Do we have a setup that's failing to delete them when it should? Do devs need to do something different with their branches? I obviously don't have access to global settings but I could put in a request if that's what needs to change.
To be clear, I'm talking about going to deployment preview, selecting "promote existing release to this environment," entering in the jira number/beginning of the branch name, and seeing a million of these (which all look identical because our branch names are hella long):
deployment preview screenshot
I have read through all the Bamboo documentation relating to plans, builds, branches, and deployment, and Googled various combinations of relevant keywords and haven't found a solution. I've also asked devs I work with and they don't know either.

How to keep the branches of a plan in bamboo specs?

I use bamboo specs to backup my plans in bamboo. However, if I remove one plan and restore it back, all the branches created for this plan are missing.
I tried to use this API endpoint Enable specs for branches but it does not seem to do any effect.
Is there any way to get the configurations and variables related to the branches of a plan in specs?
So then, if we restore back a plan that has been removed, there's no need to create branches manually and set up all needed variables specific of each branch.

Is it possible to reserve a GitLab runner for all jobs/stages of a pipeline?

I'm using GitLab pipelines to run e2e tests on various physical machines (these machines are connected to the test hardware in a 1 to 1 relation). On each machine, a GitLab runner is installed. The pipeline consists of three major parts:
prepare the test hardware (deploy, configure)
execute the e2e tests (on the test hardware)
clean up the test hardware
Currently I'm doing all of this in one job, by using the before_script, script and after_script keywords. But I would like to use multiple jobs (or even stages) for this.
The problem I'm facing is, that I can't be sure that all jobs/stages are executed on the same runner. So it might happen, that the prepare step is executed on runner1 and the execute step is executed on runner2 (even in parallel), which obviously is not what I want. The preparation is more than just creating artifacts, therefore I can't simply give it to the next job.
Tags also seems not to solve this, because a tag can only be specified for one job, not for multiple, or the complete stage.
I understand that this is not the way how runners are used normally, but I still wonder if there is a way to achieve this.
Or can someone point out another approach to solve this?
I'm using GitLab Community Edition 14.3.2.
I think you have two options here for how you can split this up -
As sytech mentioned, you can tag each machine with machine-1, machine-2, etc, which will allow you to make your jobs sticky to each runner. Since you can use variables in runner tags, you could have a job at the start that checks which runner is not running tests, and sets RUNNER_TAG or something similar to that runner, so you don't have to hardcode your runner to a single box
You could not have the test boxes run the jobs directly (presumably you're using a shell runner to do this today), and use SSH or winRM to access the box directly, and modify it from there. Then the state of your runner doesn't matter at all. This is likely the "cleaner" way to do it, so your test boxes don't have to share resources or state with the runner

RUnnin a customized plan in Bamboo

I often have to run a customized plan in Bamboo (the same one every time). So I find the plan, do a run customized and change the environment variables and test file and do a run. This is OK but it gets old. Is there a way to save the customized plan so I can run it? Or save the changes so when I run customize plan I can select that?
You can create plan branch and override variable for it

Bamboo OnDemand: how to auto-generate snapshots?

I've been busy setting up our bamboo on demand instance to run the builds we previously ran on our local instance.
As many others have already posted about or created tickets for (see for example https://answers.atlassian.com/questions/109719/automated-ebs-snapshots-in-bamboo-ondemand, https://jira.atlassian.com/browse/BAM-11525, https://jira.atlassian.com/browse/AOD-3293), I'm facing the issue of outdated maven repositories on the attached EBS volume as the contents on those volumes are not automatically persisted when the EC2 instance is terminated/shut down.
Specifically, the post at https://answers.atlassian.com/questions/109719/automated-ebs-snapshots-in-bamboo-ondemand is more or less exactly what I want to achieve: automatic generation of a snapshot before shutdown so that all the build artifacts are preserved and don't need to be re-created the next time the instance starts up. However, I was unable to get it to run as suggested in the above post.
Is there anyone who has successfully tackled this issue? If so, how did you do it? If not, any ideas or pointers are greatly appreciated.
Regards,
Chris