releng: use worktrees for git state handling, and consider also making a worktree of the other projects to do their releng #439

New issue

Open

opened 2024-07-10 17:04:09 +00:00 by jade · 2 comments

jade commented

2024-07-10 17:04:09 +00:00

Owner

Currently our own tag pushing code is broken since gerrit doesn't accept tags with commits it's not already seen. So we would probably want to push for review to release-2.90 or so.

Also, it's not made clear to people who didn't write the release scripts that releng tag will tag the version and go into detached HEAD, but that detached HEAD should not be merged to the release branch. Rather, the release branch locally should instead be pushed for review.

Overall the git state management of this is very cursed, and I wonder if it should just be done in a temporary worktree or something to reduce confusion.

Currently our own tag pushing code is broken since gerrit doesn't accept tags with commits it's not already seen. So we would probably want to push for review to `release-2.90` or so. Also, it's not made clear to people who didn't write the release scripts that `releng tag` will tag the version and go into detached HEAD, but *that* detached HEAD should *not* be merged to the release branch. Rather, the release branch *locally* should instead be pushed for review. Overall the git state management of this is very cursed, and I wonder if it should just be done in a temporary worktree or something to reduce confusion.

jade added the

Area/build-packaging

label 2024-07-10 17:04:09 +00:00

jade commented

2024-08-08 03:39:12 +00:00

Author

Owner

I think the way this should evolve is that we have a "releng workspace" where we grab each other project and create worktrees of each from which the releng is done. Then the releng code exists in lix itself, or it moves outside, either way is fine.

We can then reuse releng work for fixing up flake inputs between the nixos module and the installer, among other things.

I *think* the way this should evolve is that we have a "releng workspace" where we grab each other project and create worktrees of each from which the releng is done. Then the releng code exists in lix itself, or it moves outside, either way is fine. We can then reuse releng work for fixing up flake inputs between the nixos module and the installer, among other things.

jade changed title from releng: clarify the git state and fix git tags/non-tags push *somehow* to releng: use worktrees for git state handling, and consider also making a worktree of the other projects to do their releng

2024-08-08 03:40:10 +00:00

jade referenced this issue from a commit

2024-08-08 04:45:05 +00:00

releng: clarify/update docs, add instructions after tag

lix-bot commented

2024-08-08 04:50:13 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1729 ("releng: fix the git push")
commit message in cl/1728 ("releng: clarify/update docs, add instructions after tag")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1729](https://gerrit.lix.systems/c/lix/+/1729) ("releng: fix the git push") * commit message in [cl/1728](https://gerrit.lix.systems/c/lix/+/1728) ("releng: clarify/update docs, add instructions after tag")