What's the meaning of on: branch of GitHub Pages Deployment ?

[danielo515]

Hello,

The documentation about github pages deployment suggest you this minimum configuration

deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN # Set in travis-ci.org dashboard
  on:
    branch: master

However, there is no explanation about the meaning of the latest option on: branch: master. What is that about? I know it is not the target branch because that is explained below, so, what is it? The branch to monitor for changes? If it is that, how does this interfere with the branches: only: configuration?

I find this quite confusing, and I can't find any reference to it.

Regards

[plaindocs]

@danielmorrison thanks for catching this!

on: indicates conditional deployment from the specific branch, which is explained but not linked to in that doc.

It is set in the example because you probably don't want to force push from multiple branches to GH pages. Maybe @timwis can confirm this?

I'll leave this issue open for now and fix the docs.

[danielo515]

Dear @plaindocs ,

Thanks for your answer.
After reading the documentation I'm still not sure about the branch options.
Does that mean that the current branch should be same as the specified on the branch: option?
For example, if I run the build script on the master, develop, and integration branches, and I have the on option set to develop the deployment will only happen from the develop branch? Not to the develop branch, but FROm the develop branch. Am I right?

[plaindocs]

That is correct.

When the build succeeds ON master, deployment happens.

[timwis]

That's right - the example config executes the deployment only on master builds. That way you don't have your feature branches being deployed as you're developing them. We didn't explain that in the docs for this deployment provider because every deployment provider uses some boilerplate example and I'm fairly certain I saw that in use elsewhere?

[plaindocs]

Thanks for the speedy reply @timwis . Yeah, you are entirely correct that a lot of the deployments use the same boilerplate. Some of that same boilerplate not at it's freshest, and could probably use some improvements, and that is on me to fix.

[markuszoeller]

How do I deal with git tags on the master branch?

The following did NOT trigger a deployment with the github pages provider:

[markus@local]$ git pull -r
Current branch master is up to date.
[markus@local]$ 
[markus@local]$ 
[markus@local]$ 
[markus@local]$ git tag
0.1.0
0.2.0
0.3.0
[markus@local]$ git tag 0.4.0
[markus@local]$ git push --tags
Total 0 (delta 0), reused 0 (delta 0)
To domain:organisation/repo.git
 * [new tag]         0.4.0 -> 0.4.0

The build log shows this message:

Skipping a deployment with the pages provider because this branch is not permitted

My .travis.yml file has this config:

deploy:
  provider: pages
  skip-cleanup: true
  github-token: $GITHUB_TOKEN
  keep-history: true
  local-dir: docs/_build/html
  committer-from-gh: true
  on:
    branch: master

[plaindocs]

Hi @markuszoeller

There is some information on tags https://docs.travis-ci.com/user/deployment#Conditional-Releases-with-on%3A

If that doesn't help the folks on support@travis-ci.org will be happy to help

[markuszoeller]

@plaindocs Thanks for the link, I totally overlooked that. I didn't find a reasonable configuration in my experiments yesterday. Will update here if I find one.

FWIW, I think this issue could be closed with the link given in #1091 (comment)

[h8nor]

1. Can I specify another branch if I want to work on changing a template in another branch?
2. Is it necessary to specify the github_token from the developer's settings if the Github defined Travis-CI in App?

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues