release-notes (and release-sdk) don't check the remotes when reusing an existing temp dir for repos

[jeremyrickard]

What happened:

When running release-notes with start-rev and end-rev provided, it was observed that the wrong repo was being cloned/updated. The tooling was using kubernetes/kubernetes instead kubernetes-sigs/promo-tools. This appears to be happening because there is an existing repo clone in the expected temp directory, however it's for another repository (i.e. k/k). The cloneOrOpenRepo function in release-sdk doesn't ensure that the repoPath given is one of the remotes.

Slack Thread For Reference

What you expected to happen:

release-notes either provides a descriptive error and directions to clean up the temp dir or it clones to a new temp dir.

How to reproduce it (as minimally and precisely as possible):

Run 'release-notes' with no temp directory on one project. Then run it again on a second project (i.e. it would have a different repo path).

Anything else we need to know?:

Environment:

• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Others:

[jeremyrickard]

@DannyBrito and I just debugged this and we have a solution and will open a PR but we wanted to chat about it first. I think the proper fix here is to update release-sdk to make cloneOrOpenRepo check that the remotes for the specified repo contain the repoPath argument and return an error if it doesn't. Then we can either handle the error in release-notes and make it create a new temp dir and go forward, or maybe it would be more appropriate to just error and provide an error message indicating that the temp dir needs to be cleaned up.

This is probably going to impact very few people since most folks aren't running release-notes for multiple projects :)

@puerco @saschagrunert wdyt?

[cpanato]

@jeremyrickard, what are the parameters that you use to run the rel-notes?

to run for another repo usually you do

release-notes --required-author="" --output=release-notes.md --start-rev v0.10.4 --end-rev v0.11.0 --org kubernetes-sigs --repo release-sdk --branch main

[xmudrii]

@cpanato I used the following command:

release-notes generate \
    --org="kubernetes-sigs" \
    --repo="promo-tools" \
    --start-rev="v4.0.4" \
    --end-rev="v4.0.5" \
    --branch="main" \
    --markdown-links

[jeremyrickard]

@cpanato yeah the issue here using you already have a temp directory with the remotes pointing at another repo, we just reuse that dir and run a git pull —rebase. We don’t check that it’s the right repo

[cpanato]

I see so the issue is we need to clean the temp dir as well

[saschagrunert]

cloneOrOpenRepo check that the remotes for the specified repo contain the repoPath argument and return an error if it doesn't. Then we can either handle the error in release-notes and make it create a new temp dir and go forward, or maybe it would be more appropriate to just error and provide an error message indicating that the temp dir needs to be cleaned up.

Yeah checking the remote and wiping the cache if they don't match is a good solution. 👍

[cpanato]

@jeremyrickard should I do the fix or you already have something?

[jeremyrickard]

@cpanato have a fix. we'll open a PR.