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

tools: Add hotfix release script #5817

Closed
wants to merge 6 commits into from
Closed

tools: Add hotfix release script #5817

Changes from 4 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
8838b15
Add hotfix release script
beautifulentropy Nov 26, 2021
5c315e6
Fix typo
beautifulentropy Nov 28, 2021
b1e5858
Addressing comments
beautifulentropy Dec 3, 2021
66ca438
Addressing comments
beautifulentropy Dec 3, 2021
b8d6e64
Only check remote tags
beautifulentropy Dec 4, 2021
2ac5e14
Adding getopt
beautifulentropy Mar 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 110 additions & 0 deletions test/boulder-tools/hotfix_release.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,110 @@
#!/usr/bin/env bash

# -e Stops execution in the instance of a command or pipeline error.
# -u Treat unset variables as an error and exit immediately.
set -eu

STATUS="FAILURE"
RST=$(tput sgr0)
RED=$(tput bold && tput setaf 1)
GRN=$(tput bold && tput setaf 2)
BLU=$(tput bold && tput setaf 4)

beautifulentropy marked this conversation as resolved.
Show resolved Hide resolved
function exit_msg() {
# complain to STDERR and exit with error
echo "${*}" >&2
exit 2
}

function print_outcome() {
if [ "${STATUS}" == SUCCESS ]
then
echo
echo "${GRN}${STATUS}${RST}"
else
echo
echo "${RED}${STATUS}${RST}"
fi
}

function print_heading() {
echo
echo "${BLU}${1}${RST}"
}

function not_yes_no() {
case "${1}" in
[yY][eE][sS]|[yY]) create_branch="yes" && return 1 ;;
[nN][oO]|[nN]) create_branch="no" && return 1 ;;
*) return 0 ;;
esac
}

function get_user_input() {
while [ -z "${create_branch}" ]; do
read -p "${1}" create_branch
if not_yes_no "${create_branch}"
then
echo "Need [yes/no], got [${create_branch}]"
create_branch=""
fi
done
}

# On EXIT, trap and print outcome.
trap "print_outcome" EXIT

print_heading "Ensuring main branch is up to date"
git fetch --all
git checkout origin/main

print_heading "Fetching details for the most recent release tag"
latest_tag_sha=$(git show-ref --tags | tail -1 | awk '{print $1}')
latest_tag_name=$(git show-ref --tags | tail -1 | awk '{print $2}' | sed 's|refs\/tags\/||')

print_heading "Latest tag:"
echo "${latest_tag_name}"
echo "${latest_tag_sha}"


print_heading "Hotfix release tag:"
if [[ "${latest_tag_name: -1}" =~ ^[0-9] ]]
then
new_tag_name="${latest_tag_name}a"
else
next_tag_letter=$(echo "${latest_tag_name: -1}" | tr "0-9a-z" "1-9a-z_")
tag_with_last_char_removed=$(echo "${latest_tag_name}" | sed 's|.$||')
new_tag_name="${tag_with_last_char_removed}${next_tag_letter}"
fi
echo "${new_tag_name}"

create_branch=""
release_branch_name=$(echo "${new_tag_name}" | sed 's|release-|release-branch-|')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks to me like, if we already have a release-branch-YYYY-MM-DD and a release-YYYY-MM-DDa tag from a previous hotfix earlier the same week, then this is going to create a new branch with the a suffix instead of continuing to use the existing branch and just adding new commits and a new tag to it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm missing something, the way that this is currently written follows the current Boulder Release Process Example:

Later on 2018-01-31 its discovered that the bug in release-2018-01-30, which was hotfixed with release-2018-01-30a is still broken! Uh oh! Since main is dirty, and contains a feature commit not present in release-2018-01-30 or release-2018-01-30a the hotfix must be prepared in a separate branch. @cpu starts a new branch release-branch-2018-01-30a by checking out release-2018-01-30a and pushing it as the release branch.

Copy link
Member Author

@beautifulentropy beautifulentropy Dec 4, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, gosh, I think I misunderstood what you were saying here. So, I don't think that this is the case at all. Up on lines 61-63 is where we pull in the information about the the latest tag and the commit associated with it:

print_heading "Fetching details for the most recent release tag"
latest_tag_sha=$(git show-ref --tags | tail -1 | awk '{print $1}')
latest_tag_name=$(git show-ref --tags | tail -1 | awk '{print $2}' | sed 's|refs\/tags\/||')

outputs:

samantha at treepie in ~/repos/myboulder (hotfix-release-script)
$ git show-ref --tags | tail -1 | awk '{print $1}'
9dbbc489ae3252c2f4c75c484d730591da0dfa71

$ git show-ref --tags | tail -1 | awk '{print $2}' | sed 's|refs\/tags\/||'
release-2021-11-30

If we shipped a hotfix, either on main, because main was still clean, or a new branch (e.g. release-branch-YYYY-MM-DDa) because main was dirty, it's fine cause we fetch the latest tag and it's associated commit SHA that we use to create a new release branch.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to replace git show-ref --tags with git ls-remote --refs --tags so that we don't end up with local tags causing a problem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, what I'm trying to say is that I think the release doc is vague or imprecise (and I'm happy to fix that next week!) and that your interpretation of what it says, while I understand how you got there, is not what I intended the last time I edited that section, and is not what we did on that 08-30 branch I referenced above.

We should never have a branch with a letter suffix.

The first time we decide we need a hotfix based on the latest normal release, we should create a new branch named after that release's tag. So when the last normal release was release-DATE, the branch would have a name like release-branch-DATE. Then we cherry pick one or more commits onto that branch, and tag its tip with the hotfix tag release-DATEa.

Then we decide we need another hotfix. We do not create a new branch: we already have one. We cherry-pick one or more commits onto the tip of the same branch. Then we tag the tip of the release branch with the new hotfix tag release-DATEb.

There's never a need to create a second release branch because there's no chance that anything we don't want to release has been landed on the release branch -- only things we specifically want to backport have been cherrypicked and tagged on it.

Basically the bottom line is that: getting the latest tag is good and necessary for computing what the name of the new tag should be. But we don't want to unconditionally create a new branch with essentially the same name -- we only want to do that if this is the first hotfix on top of a normal release. Otherwise we want to strip the letter suffix in order to compute the name of the pre-existing release branch, and check that out instead of creating a new one.

get_user_input "Create hotfix release branch: ${release_branch_name}? "
if [ "${create_branch}" = yes ]
then
print_heading "Creating new branch ${release_branch_name} @ ${latest_tag_sha}"
git checkout -b "${release_branch_name}" "${latest_tag_sha}"
git push --set-upstream origin "${release_branch_name}"

cherry_pick_sha=""
while [ -z "${cherry_pick_sha}" ]; do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is designed to let you cherry-pick multiple commits onto the release branch? I like it! Two things I'd change:

  1. take the list of commits on the command line instead of from stdin
  2. only do the push and tag after the very last one

Copy link
Member Author

@beautifulentropy beautifulentropy Dec 4, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At present this takes just one cherry-pick. I was mostly going off of experience, but I don't think I've ever had to do more than a single cherry-pick for hotfixes I've done here. I could add some flags and opt parsing to enable what you're asking for in a follow-up commit. How does that sound?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I misunderstood. If the goal is to only cherry-pick one commit, then there's no need to have this inside a while loop.

I like the idea of accepting multiple commits to cherry pick (for example: that 08-30 release branch had four commits cherry picked onto it but only two hotfix releases tagged on it). But it's certainly not necessary for v1 of this script.

Either way, I'd still prefer to take the sha1 on the command line rather than stdin so that hotfix release commands can be easily copy-pasted and reviewed for correctness before they're executed.

read -p "Commit to cherry pick: " cherry_pick_sha
print_heading "Cherry-picking ${cherry_pick_sha} to branch ${release_branch_name}"
git cherry-pick "${cherry_pick_sha}"
git push origin ${release_branch_name}:${release_branch_name}
git tag "${new_tag_name}" -s -m "${new_tag_name}" "origin/${release_branch_name}"
done

print_heading "Complete the following steps:"
echo "- Diff: https://github.com/letsencrypt/boulder/compare/${latest_tag_name}...${release_branch_name}"
echo "- Open https://github.com/letsencrypt/boulder/actions/workflows/boulder-ci.yml"
echo "- Ensure that the CI pass for ${release_branch_name} completes successfully"
echo "- Run: git push origin ${new_tag_name}"
else
exit_msg "No hotfix release branch was created, exiting..."
fi

# Because set -e stops execution in the instance of a command or pipeline error;
# if we got here we assume success
STATUS="SUCCESS"