[mandre]

fixes #237

Description

Add --post-command and --post-command-commit-message options that run an arbitrary shell command after cherry-pick(s) succeed but before the result is committed and pushed. If the command produces changes, they are staged and included in an additional fixup commit.

This is useful when backporting across major version branches where the cherry-picked code contains import paths or references that are correct on the source branch but wrong on the target branch (e.g. Go module paths, Python package versions, namespace renames).

How Has This Been Tested?

Untested, apart from the newly added unit tests. This was produced with the help of opus-4.6. The code looks good to me, but since I'm not a big javascript person, my view doesn't really count 😄

Checklist

• Tests added if applicable.
• Documentation updated if applicable.

Merge criteria:

• The commits and have meaningful messages; the author will squash them after approval or will ask to merge with squash.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work

Note: dist/cli/index.js and dist/gha/index.js are automatically generated by git hooks and gh workflows.

First time here?

This project follows git conventional commits pattern, therefore the commits should have the following format:

<type>(<optional scope>): <subject>
empty separator line
<optional body>
empty separator line
<optional footer>

Where the type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test]

NOTE: if you are still in a work in progress branch and you want to push your changes remotely, consider adding --no-verify for both commit and push, e.g., git push origin <feat-branch> --no-verify - this could become useful to push changes where there are still tests failures. Once the pull request is ready, please amend the commit and force-push it to keep following the adopted git commit standard.

How to prepare for a new release?

There is no need to manually update package.json version and CHANGELOG.md information. This process has been automated in Prepare Release Github workflow.

Therefore whenever enough changes are merged into the main branch, one of the maintainers will trigger this workflow that will automatically update version and changelog based on the commits on the git tree.

More details can be found in package release section of the README.

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟢	Statements	87.35% (-0.46% 🔻)	670/767
🟢	Branches	82.26% (+3.28% 🔼)	320/389
🟢	Functions	85.48% (-1.04% 🔻)	159/186
🟢	Lines	87.43% (-0.46% 🔻)	647/740

Show new covered files 🐣

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / script-service.ts	100%	100%	100%	100%

Show files with reduced coverage 🔻

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / pr-configs-parser.ts	98.72% (-0.06% 🔻)	97.44% (-1.28% 🔻)	100%	98.65% (-0.05% 🔻)
🟢	... / git-client-factory.ts	91.67%	75% (-2.78% 🔻)	100%	91.67%
🔴	git/git-cli.ts	60.27% (-15.73% 🔻)	37.93% (-7.78% 🔻)	80% (-14.44% 🔻)	59.72% (-15.62% 🔻)

Test suite run success

245 tests passing in 20 suites.

Report generated by 🧪jest coverage report action from 7ad68bb

[lampajr]

Thanks @mandre , overall looks good and working!! It seems pretty easy to give it a try imho 🚀

I just left one nit-picking comment and maybe it might be better to move the "runScript" method into another service as it is not git-related.

[lampajr]

I'd rename this to something a bit more generic, e.g., runScript, as this might be used in the future for other hooks (e.g., pre-command)

[mandre]

Good idea. This is now done with 7ad68bb

[mandre]

Sorry for the lag. I've extracted runScript as suggested, in a second commit. If this is fine, I'll squash the commits to keep clean history.

[lampajr]

Sorry for the lag. I've extracted runScript as suggested, in a second commit. If this is fine, I'll squash the commits to keep clean history.

Hey @mandre , overall looks good to me but there are a couple of things that should be fixed

• Given the recent changes in main I believe this branch should be rebased and all conflicts resolved.
• With the default empty-commit behavior of drop, cherry-picking an already-applied change can leave the branch at the target commit. The post-command runs before that condition is checked, and this could result in unwanted behavior. We should check whether cherry-picking changed the branch before running the command.
• A failed command can contaminate the next backport. The runner continues to the next target using the same clone and I don't think this is something we want. We should clean-up the working tree after a failed command before continuing.