Skip pull request

[Eomm]

Right now the process to release a module would be:

• trigger the action manually
• go to the PRs page and merge the new PR
• approve the optic otp

I wonder if we can skip the 2nd step and go straightforward from triggering the action and approve the optic OTP.

In this way:

• if the publish fails the main branch does not contain the wrong version
• the flow is much more simple for the user. Action: trigger the workflow, Reaction: optic notification
• the new version should be committed only if the npm release is successfully

[simoneb]

What you describe was the original idea and at some point we had that implementation and we tried it out, just to realize that it wouldn't work because often the main/master branch is protected, meaning that direct pushes won't work.

Hence, we opted for this alternative solution which opens a PR. Any contributor can approve and merge the PR, thereby circumventing the issue.

I have already reached out to @salmanm about removing the need to have a backing server app since this recent change in github: https://github.blog/changelog/2021-10-06-github-actions-workflows-triggered-by-dependabot-prs-will-respect-permissions-key-in-workflows/

I am not sure but I don't think that even with that we'll be able to skip the PR. In any case, I don't have big issues with this action opening a PR. The PR will also contain a preview of what will be released so a maintainer can review what's going to happen before making it happen.

[Eomm]

I think it could work instead.

Reading the permission docs we need:

• the contents permission on the workflow
  • https://docs.github.com/en/rest/reference/permissions-required-for-github-apps#permission-on-contents
• the code should call the GitHub API instead of running git commands (it should require the blob creation too for the tree parameter)
  • https://docs.github.com/en/rest/reference/git#create-a-commit
  • https://docs.github.com/en/rest/reference/git#blobs

I agree that the commit list is useful, but providing the semver at the GH Action run assumes that the developer has already the commit list

[simoneb]

I think it could work instead.

Why? If a branch is protected you can't push to it, and I assume this is true regardless of how you try to push to it (though we haven't tried I believe)

[Eomm]

Oh, I get it now. You were meaning these GH protection rules

I was thinking about the default main protection rules, not the additional one TBH.

So do you agree that:

• wide organizations need the PR process to support more granular permissions and rules
• a single maintainer could apply for the light process to release the modules

?

[simoneb]

Yes, I agree with your conclusions.

In the current phase we are aiming to satisfy the scenario with most constraints. Once we have that working, we can then enable features which enable simpler scenarios.

[simoneb]

this is on hold at the moment, we can't implement this feature

[Eomm]

What is blocking?

[simoneb]

This cannot work as discussed if the branch is protected

[simoneb]

In any case, even though the initial idea for this action was to do everything automatically, without going through the PR, I now believe that having a PR is actually better than not having it. Why?

Because now this action can do several things, and having a PR which explains you what is going to happen once you merge it is a feature in my opinion.

I would suggest that we close this issue.

[Eomm]

I would like to keep it open and work on this whenever I get a couple of hours.
I think that this feature fits best for (little) modules that ship one or two PRs.

[simoneb]

Relevant for this issue: https://github.blog/changelog/2022-05-17-consistently-allow-github-apps-as-exceptions-to-branch-protection-rules/