Gracefully fail when running it in the context of a pull-request

[drupol]

Hello,

I'm using your Github action in my own workflow.

I noticed that when it is run through a pull-request, it doesn't work: loophp/flake-lock-update-workflow#5

The issue is:

  Error: When the repository is checked out on a commit instead of a branch, the 'base' input must be supplied.

[cole-h]

I'm a bit unclear on what exactly you expect to happen -- are you expecting a PR to be created against this new pull request, or are you expecting the action to push directly to the PR's branch?

[drupol]

I think creating a PR against this PR is the best way to handle this.

[grahamc]

That seems a bit strange to me, I think it is much more common for these types of PRs to come outside of other PRs. Do you know of other actions that behave this way?

[drupol]

What do you find strange? Creating a PR against another PR ?

Creating PR against another PR is doable, as you can see here: loophp/flake-lock-update-workflow#5 (the latest commits).

[grahamc]

The intended use case of this action is to keep a repository's flake.lock up to date. One problem with sending update PRs to every PR that comes in is you end up with a high chance of merge conflicts.

Can you explain your use case more fully, and why you want PRs to also have flake.lock updates?

[drupol]

Hi there,

Can you explain your use case more fully, and why you want PRs to also have flake.lock updates?

It's not that I need it myself, but someone might.

Let's say we maintain multiple branches of a project, we need to update the flake.lock file in those branches.
As a PR is actually a temporary branch, I'm wondering if we shouldn't support that feature.

If the person creating a PR branched out on an outdated parent branch, then it might make sense.

WDYT?

Note: I discover this behavior by chance. Maybe we should update the action and fail gracefully when it's within a PR ? I don't know.

[grahamc]

I think we should probably not, today, support running in the context of a PR, and instead setup the cron to operate on all the long running branches.

I think it would be a good idea to detect and fail gracefully if it is in a PR.

[drupol]

I agree.

[cole-h]

Sorry it took so long to get back to this.

There's no easy way to tell GitHub (in the action itself) to "skip" it under certain conditions. I came up with one potential solution in #30, but the drawback is that the action still succeeds instead of getting marked as skipped.

However, I've opened a PR at #31 that documents how you can get GitHub to skip the action if it could ever be triggered by a PR: guard the step using our action with if: ${{ github.event_name != 'pull_request' }}.

[drupol]

Very nice ! Thanks !