k3s/docs/release/expanded/update_kdm.md

Update KDM

After the RCs are cut you need to generate the KDM PR within a few hours

Set up Repo

1. make sure the $HOME/go/src/github.com/rancher directory exists
2. clear out (remove) kontainer-driver-metadata repo if is already there (just makes things smoother with a new clone)
3. fork kdm repo
4. clone your fork into that directory as "origin" (you won't need a local copy of upstream)
   1. it is important to follow these steps because Go is very particular about the file structure (it uses the file structure to infer the urls it will pull dependencies from)
   2. go generate needs to be able to fully use Go as expected, so it is important to get the file structure correct
   3. this is why it is important that the repo is in the github.com/rancher directory, and that the repo's directory is "kontainer-driver-metadata" matching the upstream copy's name
      1. $HOME/go/src/github.com/rancher/kontainer-driver-metadata
5. checkout a new branch (something like "k3s-release-september")

Update The Channels

1. Edit the "channels.yaml" file in the root of the repo
   1. copy and paste the previous version's info directly below it
   2. if a version was skipped, there should be a comment stating that
   3. ask QA captain what the min and max channel server versions should be
   4. generate the change to the channel.yaml and commit it

Go Generate

1. Generate json data changes
   1. as a separate commit, run the command go generate
   2. this will alter the data/data.json file
   3. commit this change by itself with the commit message "go generate" (exactly that message)
   4. push the changes to your fork

Squashing Your Changes

ok, so you have all the commits and you are ready to go, suddenly someone asks you to squash all the changes to the channels.yaml and the data/data.json together. The goal is to have 2 commits, one with all the changes to channels.yaml, and one with the changes to data/data.json. They might also ask you to rebase from the upstream branch...

1. Rebasing from upstream: git pull --rebase upstream <branch to rebase from> for example: git pull --rebase upstream dev-v2.7
   1. this will pull in all of the commits from upstream's 'dev-v2.7' branch into your local copy
   2. this will rebase your local copy's history on top of that pull
   3. you will need to verify your files and force push your local copy to your origin copy git push -f origin <branch name>, for example: git push -f origin k3s-release-september
   4. you will see all of the commits for the PR re-added as part of this process, take a note of how many commits are in the PR (needed for next step)
   5. force push the rebase to your origin before moving to the next step, this will prevent a diverged head state.
2. Reset local copy: git reset --hard HEAD~<commit number>, for example if you had 20 commits: git reset --hard HEAD~20
   1. this resets your local copy to the point in git history just before your first commit
   2. before you reset make sure you are at the tip of HEAD (important for next step)
   3. look in the history in GitHub and verify that you are at the proper commit so that you don't squash anyone else's commits into your own
3. Pull in the commits after reset and squash them in your local copy: git merge --squash HEAD@{1}
   1. the HEAD@{1} is returning to where HEAD was before reset
   2. this does not actually make a commit for you, it only merges the commits into a single staged but uncommitted state
4. remove the data/data.json from the staged for commit files: git restore --staged data/data.json
   1. this does not actually restore anything, it simply moves the file from staged for commit to unstaged
   2. you want to commit the channels.yaml in a separate commit from the data.json
5. commit the channels.yaml changes
   1. this single commit will replace any/all of the previous commits
   2. I put a message like "updating channels"
6. stage the data/data.json: git add data/data.json
   1. this adds a new commit with just the changes to the data.json, replacing the previous commits
   2. make sure the commit message is go generate
7. force push the changes to your origin
   1. don't force push to upstream!
   2. git push -f origin <branch> for example: git push -f origin k3s-release-september

Create Pull Request

1. generate a PR against the default branch of the KDM repo
2. Add QA captain and k3s group to PR
3. Each time a new RC is cut you must update the KDM PR with the new release information
   1. it can be helpful to add the secondary/backup release captain to your fork so that they can also update the PR if necessary

If a PR already exists, add the new commits to the PR rather than generating a new one.

In some cases you may need to generate two PRs, ask the QA lead. For example, currently (28 Sep 2022) we generate a PR against branch dev-v2.6 and branch dev-v2.7.