on.push.branches and env.BASE_BRANCH are redundant about github-pages-deploy-action HOT 4 CLOSED

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.

from github-pages-deploy-action.

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.

from github-pages-deploy-action.

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.

from github-pages-deploy-action.

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

from github-pages-deploy-action.