travis-ci / travis-ci

Free continuous integration platform for GitHub projects.
https://travis-ci.org
8.42k stars 719 forks source link

Pull request title in environment variables #9288

Open 3nids opened 6 years ago

3nids commented 6 years ago

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 commented 6 years ago

I gave it a try: https://github.com/travis-ci/travis-scheduler/pull/131 https://github.com/travis-ci/travis-build/pull/1319

mmkal commented 6 years ago

@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:

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

https://github.com/travis-ci/travis-build/pull/1319#issuecomment-439248972

Restart will not change this environment variable.

liranmauda commented 4 years ago

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).