[FOLIO-882] How does protected master branch impact Maven releases on Github Created: 05/Oct/17  Updated: 12/Nov/18  Resolved: 26/Oct/17

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: John Malconian Assignee: John Malconian
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 2 hours, 15 minutes
Original estimate: Not Specified

Sprint:

 Description   

Since it is no longer possible to commit directly to master, the release procedure may need to be slightly changed. Explore potential pitfalls/changes in this issue.



 Comments   
Comment by John Malconian [ 05/Oct/17 ]

I forked a copy of mod-inventory-storage to do some release testing on a protected master branch. Steps are documented below.

I have the maven-release-plugin configured in my POM:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.5.3</version>
        <configuration>
          <preparationGoals>clean verify</preparationGoals>
          <tagNameFormat>v@{project.version}</tagNameFormat>
          <pushChanges>false</pushChanges>
          <localCheckout>true</localCheckout>
        </configuration>
      </plugin>

1. create a new release branch - 'git checkout -b release-5.1.1'
2. Update NEWs, etc. Commit changes.
3. Run 'mvn release:clean release:prepare'. (This process creates the git release tag 'v5.1.1')
4. Push the new branch to remote origin - 'git push origin release-5.1.1.'
5. Wait for Jenkins to do its thing and verify the build in the new branch.
6. Open Github PR to merge your branch into master.
7. Wait for verification from Jenkins and then Merge.
8. Push the release tag. 'git push --tags'

You want to push the new release tag after the PR is merged. Otherwise, you could get stuck in the undesirable state of having created a release on Github with a PR that won't merge. The tag is created during the proper commit as you can see in the 'git log' output below:

commit 9c8c0c93cf6ffa88197f2f6c766ad0ba0e075979 (HEAD -> master, origin/master, origin/HEAD)
Merge: cdf5284 b8e75ba
Author: John Malconian <malc@indexdata.com>
Date:   Thu Oct 5 10:28:07 2017 -0400

    Merge pull request #2 from funkymalc/release-5.1.1
    
    Release 5.1.1

commit b8e75ba2fc1302cf6f2445b9c74198f0ddeb7483 (origin/release-5.1.1)
Author: John Malconian <malc@indexdata.com>
Date:   Thu Oct 5 14:24:20 2017 +0000

    [maven-release-plugin] prepare for next development iteration

commit 1f855d3ad0e7f8dea4cf26d1923143a5b0f8706c (tag: v5.1.1)
Author: John Malconian <malc@indexdata.com>
Date:   Thu Oct 5 14:24:20 2017 +0000

    [maven-release-plugin] prepare release v5.1.1

This all seems to work. However, I wonder what happens if someone merges a commit to master before you merge your release branch back into master. That seems wrong somehow. Any other unusual cases or concerns that we should be aware of?

Comment by Adam Dickmeiss [ 06/Oct/17 ]

master or other branch .. It does not matter.. The point in git history of the "release" is fixed. Nobody can change history BEFORE the point. It will be a fork, but .. eventually it will be merged. Just never rebase a release, because that rewrites history! I recommend not rebase except inside your very own branch.

Comment by Adam Dickmeiss [ 26/Oct/17 ]

Isn't this solved?

Generated at Thu Feb 08 23:09:01 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.