Pull request title in environment variables

[3nids]

I would like to get the pull request title in the env variables.
It is not easily accessible at the moment.

From what I could dig into, in scheduler, the worker request needs to be extended to get the PR title
https://github.com/travis-ci/travis-scheduler/blob/master/lib/travis/scheduler/serialize/worker/request.rb
and adapt the worker
https://github.com/travis-ci/travis-scheduler/blob/master/lib/travis/scheduler/serialize/worker.rb

And in build, the var needs to be added
https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/env/builtin.rb

My knowledge to pull a request my self is too low, I could not find (did not know what to look for) the way to get the PR title.

[3nids]

I gave it a try:
travis-ci/travis-scheduler#131
travis-ci/travis-build#1319

[mmkal]

@BanzaiMan can these PRs be merged? There's a pretty big use case for this: right now: a project using both semantic-release and squash-and-merge github settings has no way to enforce that the commit messages that go into the master branches are in the right format. To explain:

• semantic-release is a tool that automatically publishes to npm based on commit messages.
• For it to work, commit messages need to be in angular commit message format
• The semantic-release library suggests tools like commitlint to enforce the format.
• That works on individual commits, but when using squash-and-merge in github, the original commit messages are moved to the body of the squash commit. The first line of the commit is the PR title, which was never validated as an angular-style commit.
• This means very often invalid commits are pushed, unchecked, to master, and deployments fail.
• Having the PR title exposed would allow adding something like this to .travis.yml: echo $TRAVIS_PULL_REQUEST_TITLE | commitlint, which would fail if the PR title itself didn't conform to angular commit message conventions, meaning that when it's squash-and-merged, the final commit message would be valid.

As far as I know there is no workaround for this - the only solution is to persuade every developer to always remember to format the PRs correctly. This ends up with around 30% of PRs failing to trigger a release.

@3nids changes look pretty innocent to me, and would solve a major pain-point!

[sheldonh]

Our use case needs the pull request body, not just the commit message.

We want the PR description to include hints as to which branches of related repos to check out for an integration test, e.g.

X-Integration-Branch: acme/frontend:master
X-Integration-Branch acme/backend:new-feature-foo
X-Integration-Branch acme/integration:test-new-feature-foo

[tadjik1]

@sheldonh should it be updated when user modifies it? let's say I have created PR and travis runs a build for this. Then I have edited body/title and press "Restart" build. Should it be new body/title in this case? cc @BanzaiMan

[sheldonh]

@tadjik1 Ah, that's a good point. The answer is "yes", but Travis probably shouldn't have to deal with that. I'll just deal with that in a script: I can use the PR number to fetch the body from Github.

Thanks for helping me think.

[tadjik1]

@sheldonh that's what I did as well. the problem here is that github has very strict rules about unauthorized requests. it could be simply that github returns you rate limit error and you can not resolve title and/or body.
you could solve it by providing your github token in env variable but it will work only for commits in your repo and not - for pull requests from forks.

in the end I have decided to not to rely on pull request content at all, it's the only resilient way.

[BanzaiMan]

travis-ci/travis-build#1319 (comment)

Restart will not change this environment variable.

[liranmauda]

I needed a way to get the PR title, eventually, I did curl to the GitHub for getting it.

In the travis.yml I have added:

env:
  global:
    - PR_TITLE=$(curl https://github.com/${TRAVIS_REPO_SLUG}/pull/${TRAVIS_PULL_REQUEST} 2> /dev/null | grep "title" | head -1)

Then:

Edit the headline and restart the travis job (by going into travis and manually restart, or by pushing a commit).