Adjust release scripts to work with scripts as monorepo

[pothos]

The change prepared in flatcar/scripts#699 means that we don't use the coreos-overlay/portage-stable repos anymore.
Skip these repositories and the submodule handling, too. Leave existing logic there to support doing releases the old way (at least for the nearer future).

How to use

Merge before trying to do a release. Also required for proper output in the image-changes job.

Testing done

• Make a new branch with change on top of the current PR (use the mirror script for that even if it's easy to do manually) ./mirror-repos-branch t-lo/merge-submodules-to-paths kai/t-lo/merge-submodules-to-paths
• Then tag this with the release script SCRIPTS_REF=origin/kai/t-lo/merge-submodules-to-paths SDK_VERSION=1.2.3 VERSION=1.2.3 CHANNEL=main ./tag-release (see diff needed below)
• and run the show-changes script as flatcar-build-scripts/show-changes origin/t-lo/merge-submodules-to-paths main-1.2.3, FETCH=0 flatcar-build-scripts/show-changes alpha-3549.0.0 main-1.2.3, and FETCH=0 flatcar-build-scripts/show-changes beta-3510.1.0 alpha-3549.0.0 (to test for regressions)

Local test diff for tag-release was

diff --git a/tag-release b/tag-release
index aca1bcf..e105c98 100755
--- a/tag-release
+++ b/tag-release
@@ -26,6 +26,9 @@ if [ "$CHANNEL" = lts ] && [ "$MAJOR" = "2605" ]; then
   MAINT="flatcar-lts"
 fi
 
+MAINT="kai/t"
+MAJOR="lo/merge-submodules-to-paths"
+
 SCRIPTS_REF="${SCRIPTS_REF-origin/$MAINT-$MAJOR}"
 OVERLAY_REF="${OVERLAY_REF-origin/$MAINT-$MAJOR}"
 PORTAGE_REF="${PORTAGE_REF-origin/$MAINT-$MAJOR}"

[pothos]

A problem is that for the next round of releases we would have to run it manually twice, one from the old release tag to the last commit ID before the switchover, then for the new commit ID after the switchover to the release tag.

Or we could run hardcode the commit IDs from before and after the switch and handle this case explicitly by running the git diff twice. Instead of hardcoding it could work to use git log to find the appearance or disappearance commit of something related to the switch.

[pothos]

New alternative, wait for the next round of releases to happen for all channels.

[pothos]

A problem is that for the next round of releases we would have to run it manually twice, one from the old release tag to the last commit ID before the switchover, then for the new commit ID after the switchover to the release tag.

Instead of hardcoding it could work to use git log to find the appearance or disappearance commit of something related to the switch.

This is implemented now.

[krnowak]

I'm wondering if this handling will actually be needed, because we plan the next releases to use the submodules for both old and new releases, then we switch to merged scripts by retagging the newest release. So after that we are going to have both old and new release using merged scripts.

Also, I'm thinking that with merged scripts repos, we will abandon the changelog directories in sdk_container/src/third_party/<repo> in favor of using the toplevel one, right?

[pothos]

I think it's good to be able to diff releases instead of having a had break.

Yes, future entries can directly go to /changelog/ in scripts but the old ones should stay there.

[pothos]

Having this also is an alternative to doing the retag, which I think it more elegant - specially when there are follow-up fixes needed to get the build working and other changes also start to slip in.