nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Describe exactly when Bamboo workspaces are cleaned/removed?

Paul Smith

The Atlassian documentation often frustrates me. It provides relatively clear instructions for the straightforward operations that they expect people to perform, but there's virtually no detailed information about how the system operates beyond that.

For example, I'm trying to understand exactly when when Bamboo (4.4.3 but we expect to upgrade to 5.0 next week) will remove workspaces for builds that it's done. We have auto-branching enabled (using a Git repository) for some of our plans, and we're running out of disk space. I have expiration set for 7 days on these plans since they're for developers' personal builds. The Bamboo server believes that these builds are deleted: there are no logs, artifacts, etc. for these branch plans.

When I go look on the system, I see a large number of ancient workspaces (from March etc.) chewing up lots of space. If my base plan ID is MAIN-BRANCH then these auto-branch workspaces will have names like MAIN-BRANCH1, MAIN-BRANCH24, etc.

Can anyone explain how Bamboo manages these workspaces? When they are deleted, if ever? When they are reused, if ever? Do I have to clean them up myself?

Accepted answers

Przemek Bruski

These workspaces are not removed. They are also never reused. Yes, you'll have to clean them up yourself. I've opened an improvement request for this: https://jira.atlassian.com/browse/BAM-13589 .

All comments

Przemek Bruski

These workspaces are not removed. They are also never reused. Yes, you'll have to clean them up yourself. I've opened an improvement request for this: https://jira.atlassian.com/browse/BAM-13589 .

Paul Smith

Well that's depressing, but at least I have an answer!

So the next question is, how do I know when I can delete these workspaces? That is, how do I know which workspaces are still needed by Bamboo plans, and which are not?

Is there some facility in Bamboo that would make this easier? Or do I have to completely invent it myself?

Thanks!

Przemek Bruski

It's doable but not simple. You can use https://docs.atlassian.com/bamboo/REST/5.0-SNAPSHOT/#d2e101 to get all plans and then use the branch REST endpoint to get all branches for each plan. Anything you haven't found has to be deleted.

You could also delete everything once per month/fortnight. That's way simpler.

Jason Monsorno2

What is considered a workspace? How does that relate to a working copy?

Jason Monsorno2

I've only used 4.4.5, 5.0.0, & 5.0.1. I have a single instance running on our own hardware running. With 1 local build agent it always reused the working directory, now running with 15 and they are still reused but seems like only by the local build agent that created it.

There is this option is the job edit.

We use Subversion, but there is even an option to force clean remove a checkout which would also suggest the directory is reused:

Paul Smith

Hi Jason. Thanks for your note. However, I'm aware of that option and it's not what we want. That option will clean out the working directory after every build, which means that the next build will take significantly longer even if there's only a small change. Preserving the previous build, at least for us, drastically reduces built time for the second and subsequent builds which is important.

Also, I agree that each plan will create one working directory (per agent that it's built on) and re-use it. However, we are using the auto-branching feature of Bamboo. Perhaps you're not familiar with it, but this allows a given plan to be run with distinct build numbers for each branch that exists in the source repository.

In our environment Bamboo builds are not just the purview of the "release engineering" team creating official package builds; every developer must get a clean build (unit and functional tests are integrated with the build as well) on their private branch before they are allowed to merge into the mainline development branch. Also we don't have enough machines for each developer to have a personal Linux, Mac, and Windows system to themselves so we use the Bamboo build agents to work out portability issues that are not found on the developer's personal machine.

So, we have a LOT of personal developer branches being automatically created in Bamboo, and a small number (usually more than 2 but less than 15 unless it's a big change) of builds per branch. So we don't want to clean the working directory after each build, but we DO want to clean them eventually, when they're no longer needed, otherwise we run out of storage on the build systems and builds start to fail. And of course, forcing a clean build only before each build is really not what we want: it's the worst of all worlds (slow builds AND we still use all the same amount of disk space).

Jason Monsorno2

We do the same thing but able/willing to deal with the extra time. We have had problems with folders being moved out to library projects and referenced as an external. If the update goes over multiple revisions it can corrupt the checkout/working copy; this was the easiest (not the fastest) solution to not have to manually find and delete a single working copy.

Paul Smith

You might consider a more robust SCM solution then :-p. We've never had these sorts of issues with Git.

Ron Chan2

We've come across an issue on how this "reuse of branches" causes problems with Deployment projects.

- Create a release ("release-PROJ-1") and link to build PROJ build #1 (e.g. Bamboo url http://localhost:8085/browse/PROJ0-1)
- Deploy this
- Then at some point when Bamboo expires this particular branch
- Creating a new branch, and say it happens to use the same url
- When you try to create a release linking to this new branch, Bamboo says:
"No release with the artifacts of this build exists."

Seems the Bamboo release will still reference the url of the old branch even though a new one has been created (which just happens to reuse it).

This has got to be a bug. Has anyone seen this before?

The only short-term workaround I can think of is to have Bamboo NOT expire any of our branches, so that each branch url is distinct. However, since we have over 200 build plans and use branches heavily, that also prevents us from easily cleaning up unreleased branches.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bamboo

bamboo-administration

repository

housekeeping