According to the github graphql API docs the createCommitOnBranch method takes a FileChanges object as input which is composed of one or more adds or deletes. A rename action should be modeled as an add of the new filename + delete of the old filename: https://docs.github.com/en/graphql/reference/input-objects#modeling-file-changes
The entrypoint.sh script parses the output git status -s --porcelain=v1 -z to detect each add / delete. The -z flag NUL terminates each "line" and is recommended for programmatic consumption of git status output. The tricky part here is that -z also uses a NUL to separate the old and new file name. We have to account for this extra NUL when an R (rename) action is detected by reading an additional chunk inside the loop to get the new filename.
$ git status -s --porcelain=v1 -- .
M README.md
R action.yaml -> action.yaml.new
$ git status -s --porcelain=v1 -z -- . | cat -tve
M README.md^@R action.yaml.new^@action.yaml^@%
Implement handling of renamed files.
According to the github graphql API docs the
createCommitOnBranchmethod takes aFileChangesobject as input which is composed of one or moreaddsordeletes. A rename action should be modeled as an add of the new filename + delete of the old filename: https://docs.github.com/en/graphql/reference/input-objects#modeling-file-changesThe entrypoint.sh script parses the output
git status -s --porcelain=v1 -zto detect each add / delete. The-zflag NUL terminates each "line" and is recommended for programmatic consumption ofgit statusoutput. The tricky part here is that-zalso uses a NUL to separate the old and new file name. We have to account for this extra NUL when anR(rename) action is detected by reading an additional chunk inside the loop to get the new filename.