Description of the feature request
On Bitrise, updating a pull request will set the “Commit message:” to the "pull_request": { "title": as received from the GitHub webhook payload. This is not the commit message, only the pull request title. I would like the commit message to display the actual commit message. This can be fetched via the API using the SHA1 mentioned in the payload. The competition, who shall not be named, have built out a beautiful web UI experience that includes this information. It would be nice to not regress from a UX perspective.
Use case / for what or how I would use it
I would look at the commit message and read it. Currently updating PRs produces an endless stream of identically titled commits which is unhelpful.
Thanks for the #feature-request @bootstraponline! 
We have something similar / related on our roadmap.
A question did arise @bootstraponline : where would the PR’s text go / be available? For some use-cases we need the PR’s text too, not just the commit message.
I think you’d have to experiment with the design? The current workflow isn’t helpful because each push to a PR is identical.
Definitely don’t call it a commit message though. PR text is not a commit message. That should be a new field I think.
Another thing came up in our discussion: a PR builds is not the same as a commit build.
If you have your dependencies locked and other side effects minimized (e.g. don’t use cache) a commit/push build should result in the same build output. If it passes the first time it should always pass as you test the same state of the code every time.
A pull request build on the other hand might not test the same code in case of a rebuild, by design. When you run a PR build that will test the source branch merged into its target branch. E.g. if you start a PR from feature/a with a target branch master, the first build might pass, but then if someone updates master in a way which breaks compatibility with your feature/a branch then a rebuild will fail.
We definitely see your point @bootstraponline, don’t get me wrong, it’s just that PR builds should not look the same as push/commit builds as they are quite different by design.
In that you’re totally right, we should rename the whole thing to be called “build message” - e.g. if you start a manual build the message there will be the message you provide (by design).
The commit message exported by the Git Clone step of course will always expose the commit’s text/message, I believe this is noted in the docs that if you need that you should use the output from Git Clone or expose with git (and a Script step) directly.
I think a successful design will highlight all the important information, adapting to whatever type of build it is (PR or push). I’m only pointing out some issues (commit message being hidden is unfortunate). I don’t have a solution. The other CI vendors have solved this with their designs. In general I think this is one area where Bitrise has lots of room for improvement.
Minor nitpicking: not just the title of the PR; the title is used as the first line, followed by a newline, and then the rest of the PR’s description.
1 Like
