Documentation request: What is your suggested use of this plugin? #40
Comments
|
Hi! In my case, I want the CHANGELOG to be updated, as it's easier to read changes in multiple releases rather than checking each release notes in GitHub releases one by one. To update that file, it needs to be committed to the repository, to the main branch of it. A usual scenario is that you set your main branch as protected and set some checks need to pass in a pull request to prevent commits that would break your app to getting to your main branch. Such as a build, lint, test, ... CI. When doing that, you can no longer push to your main branch without passing those checks. So in order to push the updated
As you point out though, if opening a pull request after the release has been done, those files won't be included in the release. But in my case, I prefer this than the other options because I want my main branch protected & there's no plugin for option 2. For me, By the way, I wanted to take a look and fix the issue to use this plugin (can't be used due to #148 ) but seems the repo is not actively maintained (lot of dependabot PRs hanging around). So I eventually used an external action to publish release assets after the release with a PR: https://github.com/davidlj95/ngx/blob/669cb0ec294c351bbaa603cbe74fb478db878025/.github/workflows/reusable-release.yml#L56-L72 |
The semantic-release plugin "semantic-release-github-pullrequest" allowing the GitHub PR creation is broken (https://github.com/asbiin/semantic-release-github-pullrequest). The following PR need to be merged, but it seems like the repository is no longer actively maintained: asbiin/semantic-release-github-pullrequest#148. The motivation for maintaining a `CHANGELOG` file is well-explained here: asbiin/semantic-release-github-pullrequest#40 (comment). So here comes this change aiming to replace this broken dependency. For that, we rely on the GitHub CLI for creating PRs (https://cli.github.com/manual/gh_pr_create). Since it can be not trivial to clearly understand the `CHANGELOG` file generation, committing and pushing process, here is a summary: 1. The changelog file is generated/updated by the `@semantic-release/changelog` plugin when executing the `semantic-release` CLI. No Git action is performed by the plugin, meaning additional steps are required, hence the followings. 2. Create a branch from the current release one (e.g. "main") and switch on it since it will be used at PR creation time. *NOTE: the `github.ref_name` context value point to the branch against which the workflow has been dispatched. While the "main" branch is considered as a release one, that's not the only one (cf. `branches` option from the `release.config.js` file). This means we must be able ensure that the behavior will work in a generic way (e.g. creating a PR against the "alpha" branch).* 3. Commit the changes made specifically to the `CHANGELOG` file 4. Push the changelog branch to the remote 5. Create a GitHub PR The Git configuration has been adapted in order to state explicitly that the committer is a GitHub bot (i.e. the "[bot]" suffix in the name follow convention + is interpreted by the GitHub UI in the end). The current bot email has been selected so that a beautiful GitHub logo is displayed when checking the author associated to a given commit (e.g. 30dd7ae) and when checking the contributors (https://github.com/Djaytan/mc-jobs-reborn-patch-place-break/graphs/contributors). You can find explanation here: https://github.com/orgs/community/discussions/26560#discussioncomment-3252339.
The semantic-release plugin "semantic-release-github-pullrequest" allowing the GitHub PR creation is broken (https://github.com/asbiin/semantic-release-github-pullrequest). The following PR need to be merged, but it seems like the repository is no longer actively maintained: asbiin/semantic-release-github-pullrequest#148. The motivation for maintaining a `CHANGELOG` file is well-explained here: asbiin/semantic-release-github-pullrequest#40 (comment). So here comes this change aiming to replace this broken dependency. For that, we rely on the GitHub CLI for creating PRs (https://cli.github.com/manual/gh_pr_create). Since it can be not trivial to clearly understand the `CHANGELOG` file generation, committing and pushing process, here is a summary: 1. The changelog file is generated/updated by the `@semantic-release/changelog` plugin when executing the `semantic-release` CLI. No Git action is performed by the plugin, meaning additional steps are required, hence the followings. 2. Create a branch from the current release one (e.g. "main") and switch on it since it will be used at PR creation time. *NOTE: the `github.ref_name` context value point to the branch against which the workflow has been dispatched. While the "main" branch is considered as a release one, that's not the only one (cf. `branches` option from the `release.config.js` file). This means we must be able ensure that the behavior will work in a generic way (e.g. creating a PR against the "alpha" branch).* 3. Commit the changes made specifically to the `CHANGELOG` file 4. Push the changelog branch to the remote 5. Create a GitHub PR The Git configuration has been adapted in order to state explicitly that the committer is a GitHub bot (i.e. the "[bot]" suffix in the name follow convention + is interpreted by the GitHub UI in the end). The current bot email has been selected so that a beautiful GitHub logo is displayed when checking the author associated to a given commit (e.g. 30dd7ae) and when checking the contributors (https://github.com/Djaytan/mc-jobs-reborn-patch-place-break/graphs/contributors). You can find explanation here: https://github.com/orgs/community/discussions/26560#discussioncomment-3252339.
Hi,
I like the idea of this plugin and wanted something similar instead of having releases written directly to
main.I wasn't able to figure out how to do it with
semantic-releasethough so I'm curious if you would share your suggested workflow for this plugin.For example, semantic-release will create a tag when it runs but then this plugin will create a pull request of the release assets meaning they won't be included in the scope of the release tag, right?
I'm curious on how you get around this or what your workflow is like!
Thanks!
The text was updated successfully, but these errors were encountered: