search

openssl / project

Tracking of project related issues
2 stars 1 forks source link

Automate feature branches rebasing #854

Open quarckster opened 1 month ago

quarckster commented 1 month ago

Feature branches rebasing can be automated to make the maintenance easier. On each push to master branch a GitHub Actions Workflow will perform rebase of the branch with this command git pull --rebase origin master and push it back to the origin. Of course it will work only with simple cases. If the CI fails the maintainer still needs to perform the rebase manually.

Acceptance criteria

levitte commented 1 month ago

When pushing, please use git push --force-with-lease rather than git push -f

t8m commented 1 month ago

There is a major issue with this. Every rebase of a feature branch requires rebasing all PRs that are targeted against the feature branch. I do not think we want this.

However it would be still actually beneficial to have such automate rebasing job (I would do it as a daily CI job.) to check whether there are conflicts or CI failures triggered by the rebase. The rebased branch would not be pushed back to the repo though as there is no point in pushing it when there are no conflicts and when there are conflicts, it obviously cannot be pushed anyway.

quarckster commented 1 month ago

Every rebase of a feature branch requires rebasing all PRs that are targeted against the feature branch. I do not think we want this.

This will happen anyway when you manually rebase the feature branch. I assume PR authors are responsible for their branches to keep them up to date. Also I don't think rebasing the feature branch forces PR authors to rebase their branches immediately.

t8m commented 1 month ago

This will happen anyway when you manually rebase the feature branch. I assume PR authors are responsible for their branches to keep them up to date. Also I don't think rebasing the feature branch forces PR authors to rebase their branches immediately.

Yes, but there is no point in causing this on every push to the master branch!! Basically every push to the master branch would make all PRs against the feature branch obsolete. That does not make any sense.

Pushing the rebased feature branch (when there are no conflicts) back to the repo does not even bring any real benefits so why would we do it? When rebasing manually what matters is the conflict resolution and review, not that there are additional non-conflicting commits in the history on the master branch.

baentsch commented 1 month ago

As a [potential|soon] maintainer of 3 feature branches, I'm indeed worried what additional work this will cause for me (following master for months...) -- but then again, I've never done this... I tend to agree that automated re-basing is not realistic. But what about a compromise (Switzerland talking :)? Run a regular (nightly? weekly?) job for feature branches trialing a re-base to "master" and reporting (in case of conflicts) this to the person responsible for the feature branch?

This way, the feature branch maintainer can quickly gauge the conflicts and (decide when to) fix them (e.g., before they're getting too many/hard) while still being alleviated of the need to do that (checking) himself regularly.

quarckster commented 1 month ago

Pushing the rebased feature branch (when there are no conflicts) back to the repo does not even bring any real benefits so why would we do it?

The maintainer does not need to do it manually and CI can be run against the rebased branch. With everything said let's stick on nightly job which will do the rebase of all feature branches and run the CI checks. The branch won't be pushed back to the repo.