GitHub Actions still do it very wrong, especially in the only useful case of rebases. Here's my story: for a particular repository I was asked to add a GitHub

GitHub Actions still do it very wrong, especially in the only useful case of rebases. Here's my story: for a particular repository I was asked to add a GitHub Action that would prune all the output from Python notebooks, purge the history of ever having any outputs and push the new history into the target branch. The premise here was that eventually the branches with commits containing extra notebook content would be deleted and GC'd, so they didn't need special processing. The problem here is that GitHub doesn't set base correctly when a PR is from the branch to itself. It just sets it to all zeros hash... someone didn't test the edge case over there... Anyways. This isn't really a problem. This is just me trying to cope with a much larger problem with how GitHub CI works. Ideally, if I were to design my own system (and I've done this twice so far), any tests, any PR-associated work need to happen in the candidate commit that is about to be pushed into the target branch. This candidate is produced by rebasing the source of the PR onto the target of the PR (i.e. it's still on the source of the PR branch). Once the tests pass, the generated commit is pushed onto the target branch and the target's branch head is updated. Instead, GitHub rebases, pushes the generated commit from the source branch into the target, and runs the PR-associated CI code afterwards. This is bad, because especially if the PR-associated code wants to process PR history, it needs to generate a new PR... so, anything like enforcing code conventions, removing potentially sensitive information etc. is... impossible, because the action exposes this information too late.