Disk Space Strategies for deployable artifacts

Gretchen

I'm starting a new set of builds for a compound project (it has a variety of deployable objects, some are compiled and some are not, mainframe, database, java, cobol). I have a defined set of output folders and need to preserve these for potential future use while cleaning up the rest of the deployment and the build jobs that created them primarily for feature testing. (qa, uat, dev).

I'm intrigued by the shared artifacts but after reviewing the documentation I didn't clearly see how that would work with the build expiry function. It seems to be storing the shared artifacts in a build folder (under xml-data/...) which would presumably be deleted when the build is expired. (We are at this moment having issues with disk space on our remote agent server and are looking at what we will need to do for managing that).

I could check the zipped deployment into SVN (though that wouldn't be my first choice). Copy it out to a filesystem location. Is this my best choice? Create a deployment project to copy the shared artifacts/deployment code to a secondary location? Am I on the right track here or is there another approach I'm not thinking about?

Sean Dockery

We create an artifact definition for everything that we might want to preserve and then use labels to exempt specific builds from build expiration policies. Aritfacts are always pushed to the Bamboo server, so you need only worry about managing a large amount of storage there. If you are running up against disk space on the Bamboo server itself, you'll need to download them manually to a separate file server yourself or develop a manual or automated stage in your plan that can copy the artifacts to a known location. One challenge with the latter approach is that your Bamboo service user will need to have appropriate permissions to access network fileshare locations.