feature: Sign Commit with Github Apps

[Jno21]

Hello everyone 👋

Context:
We wanted to use semantic-release in our company, after multiple iteration we arrived to something that could be secure and easy to implement for all our repository.
One issue we have was to be able to still use Semantic-release while having protected branch. We can't use the default GITHUB_TOKEN, we would prefer not using PAT since it needs an user account and it is quite tedious to handle at scale.
So the idea is to use Github Apps and generate a Token on the go, this idea came from this discussion: #175

That worked perfectly for us and really simplify the whole workflow. However we also need to enforce Commit Signin !
With the typical workflow of semantic-release with:

  - '@semantic-release/release-notes-generator'
  - '@semantic-release/changelog'
  - '@semantic-release/git'

The commit won't be signed, to do this we would need to inject a GPG key. Again I feel this is a tedious process and it will mean share this GPG on all our repository that use semantic-release.

Github however is supporting signing commit via Github Apps. So this is the feature request.

Feature:
Add a options to commit with the Github API to have sign commit from Github Apps.

The idea is to kind of replace what @semantic-release/git do by using the Github API directly which will simplify worfklows and use what Github offer to us (Even tho, it is not always the best way).

Implementation:

I already did a dirty PoC so here is a the global idea. We can all discuss around this and improve it of course.

Adding a prepare step in @semantic-relase/github which will execute if SignCommit var is enabled:

• Get modified files
• Do an inventory of files to commit (We can do an assets filter like in @semantic-relase/git)
• Commit the files via API CreateCommitOnBranchInput
• when done continue to the Publish phase.

I can share my PoC, there is a lot of work to do on top (testing, linting etc...). Here the result:

I think it will be a great addition to this repo. We could add a documentation explaining the flow (Github App -> PAT generation -> Semantic-release), it is a way easier flow to implement than anything else I have seen so far.

Thank you, 🙏

Documentation around it:

• https://github.com/orgs/community/discussions/50055
• https://github.com/Nautilus-Cyberneering/pygithub/blob/main/docs/how_to_sign_automatic_commits_in_github_actions.md#solution-01-using-the-temporary-github_token-generated-for-each-workflow-job

[travi]

appreciate the thorough consideration of the situation. however, the complexity you describe is a big part of the reason we do not include the git plugin by default and discourage it's use. we recognize that our documentation does not currently make this recommendation big and visible enough, and we are intending to improve that situation with semantic-release/git#477.

semantic-release uses tags to track previous versions, so it does not need the version to be committed to version control to manage versions. we recommend favoring github releases over versioning a changelog.md file.

could you potentially change your workflow to remove the need for the git plugin as part of your release process? if you dont make a commit during your release, you remove the commit altogether, so there would be no need to sign it. you then also do not need to do anything special to push to a protected branch since there would be no commit to push.

while your suggestion may be a reasonable approach to make this complex process a better experience for the workflow you describe, we have to make decisions about what to invest in with our limited time to maintain the project. since we are already planning to more aggressively discourage the use of the git plugin in general, it is very unlikely that we would invest in coupling this github plugin more closely to the git plugin and add more complexity to maintain over time. if you decide to continue using the git plugin, it currently comes with the trade-off of this extra complexity. this complexity is avoidable if you are willing to make a different choice and simply avoid the use of the git plugin

[Jno21]

Hi @travi !

Thanks for your answer, it makes a lot of sense. You are totally right that just adding a Changelog.md adds a lot of complexity. Like you explain this mean:

• Having a token with enough permissions
• Commiting on the branch

So yes I think we could avoid that if we don't really need a changelog.md.

About the implementation I proposed it didn't include having to use the @semantic-release/git at all. The committing part would have been done directly in @semantic-release/github via Github API, so technically the git dependency is not necessary at all. My PoC is just using:

  - '@semantic-release/commit-analyzer'
  - '@semantic-release/release-notes-generator'
  - '@semantic-release/changelog'
  - 'semantic-release-github-jno21' // fork of @semantic-release/github that commit directly via Github API

However I can understand that this add complexity to the @semantic-release/github plugin. So it all depends on the direction this plugin takes, more precisely do we want Semantic-release to include a Changelog.md or not.

Depending on the direction this plugin takes I can help implement this feature or just ditch it and accept having the release notes only in the Release of Github.

Thank you for letting me know what you would like to do.

[travi]

that extra context is helpful and helps me frame where i think this potentially fits. i think the short answer is probably not in this plugin, even though the name of the plugin is github.

our plugin system is intended to enable swapping helpers in and out depending on the context of where your project is being released from. for example, as an alternative to the github plugin, we also have a gitlab plugin. the intent is for these to have similar functionality so the same outcomes can be enabled in both contexts. for these plugins, the focus is mostly on suing the api to add release notes, labels, and comments, not anything to do with git. we have to be mindful of the goals of the various plugins (even beyond github/gitlab).

i think the behavior that you describe is more of an alternative for the git plugin rather than the github plugin. you are more describing a plugin that has the primary goal of creating commits, but in the context of github. therefore, i think the best approach to enable this would be a new plugin that is positioned as an alternative to the git plugin that takes advantage of the abilities of github rather than the git cli. since this is not a priority for the core team right now, i think it would be best to start as a plugin maintained outside of the semantic-release organization.

if you are interested, i would encourage you to create and maintain this plugin yourself. if you do pursue this, please keep us informed and we would be happy to link to it from our documentation

[Jno21]

Hey @travi

Thanks for taking the time to answer.

I did thought about having a plugin on it's own before making a PoC with the Github plugin.
Like you said since it is a plugin called github, why no integrate this feature in it. However what you say make sense, particularly the fact that the plugin need to have similar feature between Provider (Github, Gitlab...).
As Github commit via API is very specific to Github, I can understand that it will create a gap between the plugins which might make them harder to maintain and more prone to evolve with specific features.

I will try to create a plugin on its own with this feature only to provide an alternative to the typical git one but just for Github. There might be one specific use case I am afraid I can't implement but I have to explore more the documentation of semantic-release to check it out.

Thank you, I will keep you up to date when I publish it.
Have a great day !

[travi]

sounds good. if you run into complications or come up with questions specific to semantic-release, feel free to ask in this thread and we can try to help you out. i'm going to close this issue since this isnt actionable for us, but we can still continue the conversation here related to your progress