How can I access Git repository during deploy stage?

[Jonathan Vaughn]

We need to be able to access git history (specifically, so we can run git diff between last deployed commit and commit we are about to deploy, since Bamboo doesn't appear to have any way to deploy only changes / remove only removed files). However, it appears that during the deploy stage (and possibly build stage, I'm assuming), the git repo isn't part of the artifact created during build phase.

Even if we could do it on the build step, that wouldn't help much, because we need to get ALL changes between last "release" and current "release" and deploy time, not whatever it was at build time.

We could manually clone the repo someplace during our deployment script, but that is potentially many GB of cloning that isn't unnecessary and will slow down the deploy process when ideally we could have it already in the artifact we're using.

Is there a way from a shell script to access (via variable, or such) wherever the git repo was cloned to so we can run the necessary git commands against it ?

[Jonathan Vaughn]

Version : release-${bamboo.planRepository.1.revision} Automatically increment last number in version : unchecked (disabled) The preview won't work (i.e., it will show release-${bamboo.planRepository.1.revision}), but if you create a deployment it'll be named appropriately. That just leaves the problem of "first deployment", if you set a variable(s) in your script to check that contains starting / ending commits you can use these to override the normal behavior and specify a specific commit via the script's environment variables ..

[Dex Delfrate]

I thought about trying to tag deployment release names using the commit hash, but I couldn't seem to find an appropriately accessible variable to make that happen. Could you post your exact naming scheme?

[Jonathan Vaughn]

This is basically what we've ended up doing. We're tagging releases wit the bamboo variable for commit hash (I forget what it is off hand), and the script the looks at the previous release tag, regexes the hash out of it, and the current commit hash from the bamboo variable, and runs git log both with filter D (deleted) and AM (added/modified). We then use the file list using -T to tar IIRC to create a tar of just AM files. Next, generate a script using heredoc from the script that will be uploaded to the server to deploy the files, which creates a backup tar.gz of everything from the D and AM filter output first, then deletes everything in the D filter output, then extracts the uploaded AM tar.gz, then cleans up after itself (moving these deployment files to the backup dir or removing them, depending). So we have 1. Clean working directory 2. Script (check out git repo using bamboo var to get the URL, plus all the above stuff happens) 3. SCP Task (upload the file lists, script, and tar.gz) 4. SSH Task (runs the deploy script that was just uploaded in step 3 / generated in step 2) It's far from ideal, but... it works so far *knock on wood*

[Dex Delfrate]

I'm trying to do pretty much the same thing. I've managed to come up with an inline script task (below) which will produce output of all the removed files between two revisions, but I have yet to find a way to fill in the previousRevision git log --pretty=format: --name-only --diff-filter=D {previousRevision} ${bamboo.planRepository.revision} --summary > removals.txt