Yeah, I guess its required. There are other ways of preventing Travis from building the branch. One is by changing the Travis settings so a build file is not required. Another way is to ensure the commit contains the message [ci skip] which causes Travis to ignore it and not build
A quote from another web site on building the pages,
Run only on the master branch
We don’t want any development branches to be built and pushed to our production site automatically. And moreover, if the Travis workflow is build, commit, and push to gh-pages, each build would kick off another build if we didn’t restrict it. So this goes in the .travis.yml:
What you suggest seems to mean the same thing but Im not sure if theres some subtle difference that travis recognizes between the two.
I just found a duplicate of what I see happening at stack overflow,
The answer seems to mirror exactly what I am saying but the poster didn’t respond if it worked or if they found a solution elsewhere.
I am asking rather than experimenting because I don’t want to fry the wiki by doing something stupid as I have never messed with the config before. I understand how its setup, just not the consequences of changes I may make.
Note that safelisting also prevents tagged commits from being built. If you consistently tag your builds in the format v1.3 you can safelist them all with regular expressions, for example /^v\d+.\d+(.\d+)?(-\S*)?$/.
If you use both a safelist and a blocklist, the safelist takes precedence. By default, the gh-pages branch is not built unless you add it to the safelist.
This is why I am thinking there may be a difference.
You can’t mess up the wiki because if we have to remove the config file we can just remove it and then we are back to where we started. It seems like maybe just having an identical .travis.yml file might do it. I mean, Travis isn’t going to build the other branch so it doesn’t matter anyway what you put it there since its just going to be ignored anyway.