bamboo - scm changes

Hi there,

We are presently looking at bamboo integration with our database scripts in svn.

However, bamboo treats all files in the svn directory as part of the build (ie. an entire application) - we wish to only 'build' and deploy only the files that have been created or modified in svn.

There is a tab under a build project - Commits (or Code Commits) - which lists all of the changes in the latest revision. So of course, the information is available to Bamboo itself.

Does anyone know if there is any way for our build process to access this information such that we can share an artefact for deployment which only includes created/updated svn files?

How is anyone else accomplishing this? We can't assume that all .sql files, for example, need to be deployed/executed for every new build/release.

Thank you

1 answer

1 accepted

0 vote

Why would you only build and deploy the files have changed? Deploying all of the files will actually help you in the long run - that way you know that nobody is actually altering the files that are supposed be changed through svn/Bamboo....

I would actually say that not pushing all of the files will actually be dangerous - you'll more than likely have some files which are updated directly and not updated in svn so when you do push things through svn/Bamboo - it will be bad.

Now what I would suggest is have the script that gets triggered and actually uploads the sql to be smart and only upload the files that have changed (do an md5 checksum from a previous run or look at timestamps on files). This way - if you lost the server or need to recreate things - it will be a lot easier...

Thanks for your response! Much appreciated.

Sorry, I wasn't clear.

Our Bamboo builds are triggered on svn commit. So we already know that files are changed. We just need to know which files - not all of them.


We are monitoring svn commits under:


The desired outcome is:

- any create/update commit triggers a bamboo build

- source control checkout is performed (just the changes made, if possible)

- the changed files are packaged into a shared artefact

- the 'development' deployment is run, which runs the sql on the development server

Does that make sense?

It makes sense what you're wanting to do. My point is that if you rely on the build server to know what the last successfull run was - you'll have encounter issues when the dev server is down or something else causes issues with the database connection.

If you're going to do it though - you probably won't need a plugin - take a look at the metadata on the job. In particular previous.revision.number . From that you should be able to do a svn diff

Yep, I understand. We have some other mechanisms to determine the last run, so that's okay.

I checked out the plugin and it wasn't quite what I was looking for out of the box, sadly.

I'll just run a task to do a manual svn diff.


Suggest an answer

Log in or Join to answer
Community showcase
Louis De Jaeger
Posted yesterday in Off-topic

Friday fun: your best joke

Hi all Lets make this Friday fun really fun and post one (or more) of your best jokes! The joke can be about an Atlassian product, or just a really fun joke you want to share! I’m not the best j...

35 views 1 2
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot