PULL_REQUEST_BODY does not appear to be usable for multi-line body
edwarnicke opened this issue · comments
First, thank you for the action, its super super useful 😄
When we attempt to use here to setup a PULL_REQUEST_BODY to carry the git log -1 for the commit for which
we are generating the PR.
The resulting PR is only using the first line of the body:
https://github.com/networkservicemesh/sdk-vppagent/runs/977050107?check_suite_focus=true#step:5:59
OK... looking here it appears that the issue may be in how the ::set-env is setting things
I'd first check that after you set the environment variable in the action, when you echo it again in a following step it still is the entire log.
Multiple line strings can definitely lead to issues for envars, because they will truncate after the newline, or given some unexpected quote. One thing we could try (that still likely would have issues when we add the content to the POST request) is to allow setting the body based on cat of a file (that if defined and it exists here https://github.com/vsoch/pull-request-action/blob/master/pull-request.sh#L250) would then generate that content again (without needing the ::set-env setting. There is also the idea of posting via json in this case: https://gist.github.com/ungoldman/11282441. But this is a very delicate setup because if you have one wrong quote character in the body, it's going to cut early and trigger an error. Could you figure out a way to represent the commit (perhaps just with the hash) without including the whole message? How about generating a link to the commit on the repository so you don't need to include that full body?
@vsoch Thanks for the swift reply... and I feel your pain on string escaping :)
To fill in a bit more context, we are doing go development with multiple repos. Because go will let your go.mod depend on a particular commit, when an upstream repo (A) is updated we push to a branch on the downstream repo (B) with a commit message that reflects what happened upstream. From there we use your action to open a PR (because CI!) and if that CI passed automerge.
Here's our trick: this is transitive:
A -> B -> C
can be a thing.
The commit message for the push to B contains the commit message from A.
The commit message for the push to C contains the commit message to B.
If the commit to B is an update from A, that means the commit message to B will contain the commit message from A.
The idea was to make it easier to chase down the root changes when something downstream failed CI.
We can simply reference the commit as you suggest... it requires a bit of clicking to chase things down, but it's doable.
Ultimately, it would be very very very nice to have a mode that works the way thins like hub work... where if you do hub pull-request it will, if you have a single commit, default to using the commit message to form its title/body for the PR.
I'm definitely open to a solution if you can figure something out and open a PR.
Cool :)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.