on.push.branches and env.BASE_BRANCH are redundant

[nickserv]

Describe the bug

The readme uses on.push.branches set to master as an example, but pushing to other branches doesn't deploy them anyway because of env.BASE_BRANCH defaulting to master.

Expected behavior

I think it would be less confusing and easier to change the base branch if we either removed the env.BASE_BRANCH config to deploy all matching branches or removed on.push.branches from the configuration (has the disadvantage of taking extra time to build other branches).

[JamesIves]

I think modifying the example might be better than removing the configuration option. My reasoning for that is because it's not always a push event that triggers these workflows, so there may not be a ref available in the workflow env. Scheduled jobs for example is one case where GITHUB_REF will be undefined.

The other option would be to remove the base branch configuration option and instead setup an example that uses actions/checkout that checks out a specific branch before the action runs: https://github.com/actions/checkout#usage.

Do you have any preference? Also happy to review any PR's if you'd like to make the change.

[nickserv]

I see the scheduling issue, thanks for explaining.

Now that you mention it, it sounds more consistent and reusable to let the checkout action have full control over what ref/branch is built (rather than having env.BASE_BRANCH). However, this could cause development on other branches to cause extra builds on master. Are you suggesting to keep on.push.branches in the readme to alleviate this, or is there a better alternative?

Alternatively we could use GITHUB_SHA, which is automatically set to the latest commit on the default branch in a scheduled build.

[JamesIves]

I've been thinking about this more and I think removing env.BASE_BRANCH would end up causing some issues. The reason for this is that the action switches between the deployment branch and the base branch initially to ensure the branch it's deploying to actually exists: https://github.com/JamesIves/github-pages-deploy-action/blob/master/entrypoint.sh#L55-L68

I think modifying the README example to not specify a branch in on.push would be better. The on.push branch filtering is up to the person creating the workflow, and it isn't really related to how the action works so I can see how it just adds confusion.

We could also setup some redundancy, where if env.BASE_BRANCH exists then it uses that, otherwise it falls back to GITHUB_REF and then master. This way there's one less config option and the action will work for all types of use cases.

[JamesIves]

I've pushed a change to the README in pull request #26 if you'd like to take a look!

https://github.com/JamesIves/github-pages-deploy-action/blob/example/README.md