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.
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.
Happy Friday Everyone! Today marks the international release of Disney's live action version of the animated classic Aladdin. I know that this movie was met with some controversy of over cast...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events