Role of baseBranch checkout

[Pike]

I'm struggling with the current behavior of checking out the base branch before deployment.

Is that providing a distinct benefit to existing users of this action?

Here are some thoughts on why it might be nice to not check out by itself:

PRs don't have their code easily available by a fetch on origin. This bothers me in #505.

I also started looking into this action to deploy generated docs (sphinx in my case, but also pelican). Are there many existing users that deploy checked-in files? This also ties a little into the removal of being able to switch off persist in #503, I guess?

[JamesIves]

I agree this can be pretty confusing, and it's not ideal how it works presently. I'm all for stripping this out if we can keep functionality. It would be a good overall improvement I think and probably limit a lot of bugs we've seen as a result of it in previous versions.

In general the baseBranch option is used mostly for scheduled jobs and deploying from other branches. The current SHA (which is included in the GH workflow payload by default, depending on the job type) is used if one is not provided. If the action didn't perform this step it really should be able to just deploy the files and not have to worry about stashing changes before it runs.

[Pike]

Thanks for the feedback.

My idea for projects using the previous behavior was to recommend to use the checkout action with a path, and to deploy from that subpath.

One finding I have with the github.sha is that for PRs, it's the merge commit gh does to see if there are conflicts. It's not the actual head of the PR. It's weird, but that's how they roll.

[JamesIves]

I wonder if in version 4 if we should lean more heavily on actions/checkout to make the initial checkout, essentially removing the need for the BRANCH variable at all. I'll probably experiment with this next weekend when I have a bit of time to work on this.

[Pike]

I have some cycles these days, I'll give it a spin.

[Pike]

Opened up #515