Administrator Guidelines

These instructions are only relevant to those who have been granted push rights on the upstream repository (those who are in the spring-integration-admin group). Contributors, even admin group members when contributing code, should consult the [Contributor Guidelines](Contributor Guidelines).

Merging Pull Requests

The following steps indicate a typical merge of a Pull Request once its review is complete and it has been approved by at least one team member (other than the original contributor). Note that the button on github can also merge a PR (our comment below emulates the comment it would generate), but while that will only be enabled if the PR can merge cleanly, it will not check if the PR is up-to-date with respect to upstream/master. In order to maintain a clean linear history (with only merge commits being non-linear), the following steps include a rebase (and optionally, an interactive squashing rebase as well).

// sync up
git fetch --all

// make sure your local master is up to date
git checkout master
git merge upstream/master

// grab the branch for the PR
git checkout --track johndoe/INT-123 

// make sure that branch is up-to-date
git rebase master

// get a quick view of the number of commits past upstream/master
git log --oneline

// At this point, you might even do some basic polishing, but typically
// that should be handled by the original committer via PR feedback.
// - Check copyright dates
// - Include a check for whitespace violations and fix or bounce back to contributor.
git log -p --check

// IF you want to squash (no historical value) do an interactive rebase;
// 3 in this case (HEAD~3) being an example number of commits to squash.
git rebase -i HEAD~3

// Polish the comment if necessary during the interactive rebase

// Do a full build
./gradlew build

// go back to the local master
git checkout master

// perform a fast-forward merge from the local tracking branch
git merge INT-123 --ff-only

// verify that the commit log is linear (the --ff-only should prevent non-linear merges)
git log --graph --pretty=oneline

// push to your own fork's master
git push origin master

// push to THE upstream master
git push upstream master

To avoid accidental merge commits, you can configure git to always use fast-forward on master...

git config branch.master.mergeoptions "--ff-only"

Sometimes, however, if there are a number of commits on a topic branch and it is desirable to keep them separate, then use a non-fast-forward merge instead (but you will have to remove the mergeoptions above).

// merge the local tracking branch into master with a comment having this format (and no fast-forward)
git merge -m "Merge pull request #99 from johndoe/INT-123" --log --no-ff INT-123

// polish the results of the previous --log if necessary
git commit --amend

// push to your own fork's master
git push origin master

// push to THE upstream master
git push upstream master

After the branch has been merged, if that branch did require rebasing master, then it will not be automatically closed within github. If that's the case, manually close the PR in github, optionally including a comment. GitHub will close the PR if no rebase was required, but you should check the PR list anyway.

Common Questions

1. What if my push to upstream master fails after I've merged the branch into my local master? This can occur if someone else has pushed another PR to the upstream master after your last rebase on the branch.
   The solution is as follows:

// Update your master branch
git fetch --all

//Reset the index and working tree to remote. 
git reset --hard upstream/master

// Go back to your branch
git checkout INT-123

// Rebase the branch to include all changes
git rebase master

// Do a full build
./gradlew build

// go back to the local master
git checkout master

// perform a fast-forward merge from the local tracking branch
git merge INT-123 --ff-only

// verify that the commit log is linear (the --ff-only should prevent non-linear merges)
git log --graph --pretty=oneline

// push to your own fork's master
git push origin master

// push to THE upstream master
git push upstream master

Warning: Any changes to tracked files in the local master since <commit> are discarded.

Release Process

The steps are simple, and almost everything is done via the Bamboo and Artifactory UIs.

One-time setup

Configure your CI build plan to use the Artifactory Maven 3 or Artifactory Gradle tasks as appropriate. For "Deployer Username", use "buildmaster" (password on request).

Steps at a glance

1. Stage the release into the libs-staging-local repository
2. Verify and test the staged artifacts
3. Promote the release to libs-milestone-local (or libs-release-local as appropriate).
4. Merge release branch
5. Announce the release

Steps in detail

1. Stage the release

The Artifactory Bamboo plugin mentioned above also includes sophisticated Release Management capabilities. This feature allows for publishing releases directly from CI, including creating a release branch and/or tag; incrementing the project version; and publishing to the libs-staging-local, libs-milestone-local or libs-release-local repositories as appropriate.

To access this feature, click on the "Default Job" for the Master (4.3.x) Spring 4.3.x Snapshot build plan (as an example), where you'll see a link to "Artifactory Release Management". Fill out the form fields there and click "Build and Release to Artifactory". Typical values -- in this case for a milestone release -- look something like the following: