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.
Related
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.
We're using Go.Cd and transitioning to Bamboo.
One of the features we use in Go.Cd is value stream maps. This enables triggering another pipeline and passing information (and build artifacts) to the downstream pipeline.
This is valuable when an upstream build has a particular version number, and you want to pass that version number to the downstream build.
I want to replicate this setup in Bamboo (without a plugin).
My question is: Is there a way to trigger a child plan in Bamboo and pass it information like a version number?
This has three steps.
Use a parent plan/child plan to setup the relationship.
Using the artifacts tab, setup shared artifacts to transfer files of one plan to another.
3a. At the end of the parent build, dump the environment variables to a file
env > env.txt
3b. Setup (using the artifacts tab) an artifact selector that picks this up.
3c. Setup a fetch for this artifact from the shared artifacts in the child plan.
3d. Using the Inject Variables task - read the env.txt file you have transferred over. Now your build number from the original pipeline is now available in this downstream pipeline. (Just like Go.Cd).
New to Gitlab CI/CD.
What is the proper construct to use in my .gitlab-ci.yml file to ensure that my validation job runs only when a "real" checkin happens?
What I mean is, I observe that the moment I create a merge request, say—which of course creates a new branch—the CI/CD process runs. That is, the branch creation itself, despite the fact that no files have changed, causes the .gitlab-ci.yml file to be processed and pipelines to be kicked off.
Ideally I'd only want this sort of thing to happen when there is actually a change to a file, or a file addition, etc.—in common-sense terms, I don't want CI/CD running on silly operations that don't actually really change the state of the software under development.
I'm passably familiar with except and only, but these don't seem to be able to limit things the way I want. Am I missing a fundamental category or recipe?
I'm afraid what you ask is not possible within Gitlab CI.
There could be a way to use the CI_COMMIT_SHA predefined variable since that will be the same in your new branch compared to your source branch.
Still, the pipeline will run before it can determine or compare SHA's in a custom script or condition.
Gitlab runs pipelines for branches or tags, not commits. Pushing to a repo triggers a pipeline, branching is in fact pushing a change to the repo.
I have a build plan in Bamboo (5.10.0, build 51017), and in the end of my build process, I push changes to my Git repository (Bitbucket Server), with a message with the following format: <build key>: Commit performed by the build server..
My build plan key is AAB-AC, and the commit message always starts with the key of the build, such as AAB-AC7-JOB1-75 (${bamboo.buildResultKey}).
I have tried many different regular expressions in the Exclude changesets field of the Advanced options of my repository, but a new build is always triggered whenever a build completes.
Here are a few examples of the patterns I have tried:
^AAB-\S*-\S*-\d*:
^AAB-AC\S*-\S*-\d*:.*$
^AAB-AC
AAB-AC
^AAB-AC\S*-\S*-\d*:.*\n
^AAB-AC.*$
^AAB-AC.*-.*-.*:
Commit performed by the build server
For each of these regular expressions, whenever I run a build manually, a new build is started right after my build finishes and the Bamboo server enters an infinite loop and endlessly builds my app.
How can I make Bamboo ignore the commits performed by my build plan?
Thank you for your help!
Most of those should work, we use ^Tag:.*$ in "Exclude changesets" to exclude commits like "Tag: v1.0.0" from triggering a build.
This worked in Bamboo 4, but doesn't work since we upgraded to 5.10.2 build 51019. So my guess is that this is a bug in Bamboo
I finally managed to make this work...
I have branches on my plan and I found that branch plans have their own repository definition with their own Exclude changesets setting.
So I tried all the regex combinations for nothing since the value specified on the branch plan was used, and not the value I defined on the main plan...
It seems that the ^ character is used to negate the regex, instead of matching the beginning of the string...
So the pattern ^AAB-AC seems to match everything that does not contain AAB-AC
All the commits I pushed to my server that didn't contain AAB-AC were ignored
All the commits pushed by my build plan triggered a new build
So I fixed my regex and I updated all my branch plans and everything seems to work properly.
Thank you for your help,
Best regards!
I am trying to create a build plan which has a VCS Tagging(or VCS Branching) task in its first stage, and then at later stages uses the newly created tag(or branch) to checkout code from it(repository is SVN).
I use a plan variable for the tag/branch name - ${bamboo.repoBranch} - and this variable is also used in the repository URL. I understand that this URL would not be valid until the tagging/branching task is executed, but tasks that try to checkout from that URL are at later stages.
From what I understand, there is something like a code change detection phase, during which Bamboo checks all defined repositories for changes(no matter the order they are referenced in the plan or even if they are not used in the plan at all). I think this is the reason my approach doesn't work, is that correct?
Here is the exception I get:
com.atlassian.bamboo.repository.InvalidRepositoryException: svn:
at
com.atlassian.bamboo.repository.svn.SvnRepository.detectCommitsForUrl(SvnRepository.java:527)
at
com.atlassian.bamboo.repository.svn.SvnRepository.collectChangesSinceLastBuild(SvnRepository.java:278)
Another alternative to what I am trying to achieve is to have a plan that creates a tag/branch and a child plan of that plan which uses the newly created tag/branch. The problem with this is that plan variables cannot be passed to child plans - I want to use Run Customized to override the value for ${bamboo.repoBranch} and the overridden value to be passed to the child plan. From what I've read the workaround for this is to use a script task which using the Bamboo REST API queues the next plan for execution, but this seems a not very elegant solution.
Any other approaches for what I am trying to achieve will be helpful.
Thanks