Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New release and pr-commit scripts #860
These two commits contain two changes:
Recently, someone (@ryan-williams?) mentioned the idea of moving to a branch-then-release model. Here, we would make a branch, and then make the release off of this branch. The release commits would not show up on the master branch. This would make it easier to make maintenance releases. Although the Maven release plugin contains a goal for releasing from a branch, the general consensus is that this goal works with SVN but not with Git (I tested this out and this does seem to be the case). It seems like many people advocate the "Gitflow" release approach; however, that seemed like a radical departure from our current model, so I decided not to go that route.
In this PR, we make an update on the starting branch (presumably master, but this is not hardcoded in the scripts, in case we want to make a maintenance release) to the
Once the release completes, our repo will look like this:
Once both Scala 2.10 and 2.11 releases succeed, the release script updates the pom.xml's on the master branch to the new development version.
PR Commit scripts
There are two problems with the PR merge button in Github:
If we want to merge a pull request (
We would run
Looks awesome, @fnothaft! One question: with the
One thing I noticed with the 0.17.1 release process, the link to CHANGES.md on the releases page does not contain the 0.17.1-related changes
linked from here
→ Release Notes
This PR resolves that issue.
That is correct; it will automatically rebase. My general thought is that as long as the branch has no merge conflicts, doing a rebase will achieve the same results as Jenkins achieves when it merges the branch into master when testing in the PR builder.
Oct 9, 2015
1 check passed
@fnothaft (catching up on some GH notifications) So Jenkins doesn't just check out the PR branch, but it actually creates a merge commit before running tests? This is not how I would expect it to work. In my experience, there have definitely been rebases/merges that finish smoothly but produce unexpected results.
If we look at the latest ADAM-prb build, it is doing:
The last line (
Long story short, the branch