Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Deploying a release that is not the latest merge to master can fail #810

Closed
robertknight opened this issue Nov 8, 2018 · 3 comments
Closed

Deploying a release that is not the latest merge to master can fail #810

robertknight opened this issue Nov 8, 2018 · 3 comments
Assignees
@robertknight
Labels
technical debt

Comments

@robertknight
Copy link
Member

robertknight commented Nov 8, 2018 •
edited
Loading

Attempting to deploy a release from Jenkins which is not the latest merge to master can fail as follows:

  1. Merge PR A
  2. Wait a minute or so and merge PR B
  3. Wait for Jenkins build of PR A and PR B to finish QA deploy
  4. Attempt to deploy first build (PR A) to prod.

Step 4 will create a Git tag and a commit on the master branch for the release and attempt to push that to GitHub. However this will fail because the release commit was not made against the latest version of master, but the commit before PR B was merged.

See also this Slack discussion

To resolve this, we'll either need to change the release process to avoid actually creating commits in the process, or ensure that Jenkins merges the release commit to master rather than attempting to force-push it.
@seanh
Copy link
Contributor

seanh commented Nov 8, 2018

Jenkins is trying to do a release commit on top of the latest commit that it has (which is the commit that Jenkins has tested, and that the developer has tested on QA). Wouldn't merging with other commits from GitHub mean the release commit would not represent the same code that has been tested?

@robertknight
Copy link
Member Author

After some Slack discussion we concluded that avoiding having to commit to master as part of the release would be best. We can do this by:

  • Removing CHANGELOG.md from the repo. The info will still be available in GitHub releases.
  • Having a dummy version in package.json on master and then generating the monotonically increasing version number for a release based on the last Git tag.

robertknight added a commit that referenced this issue Nov 8, 2018
@robertknight
Use atomic git push during release process
c0ee3d9 
Ensure that the release tag is only pushed to GitHub if the release
commit can also be pushed to master.

We are likely to change the release process soon to avoid the need to
push to master at all (see #810)
but in the meantime this prevents a scenario where:

 - A tag vX.Y.Z gets created
 - The package version is still at X.Y.(Z-1) on master
 - Subsequent builds of master fail because they try and fail to create
   a tag vX.Y.Z which already exists
@robertknight robertknight mentioned this issue Nov 8, 2018
Merged
@robertknight robertknight self-assigned this Jan 31, 2019
@robertknight
Copy link
Member Author

The first part of this, removing the CHANGELOG, is happening in #911

@robertknight robertknight reopened this Jan 31, 2019
@robertknight robertknight mentioned this issue Feb 4, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@robertknight robertknight

Labels
technical debt
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@robertknight @seanh