Merge pull request #10 from n0th1ng-else/examples

README.md

@@ -38,10 +38,19 @@ The plugin can be configured in the [**semantic-release** configuration file](ht
 
 ## Strategy
 
-### Github strategy (`{strategy: 'github'}`)
+### GitHub strategy (`{strategy: 'github'}`)
 
-- In case of a single commit in the branch, semantic-release analyzes that commit.
-- When multiple commits are in the branch, semantic-release analyzes the commit made of the pull request title and commit concatenation in the body.
+Once PR is merged, GitHib creates a squash commit in the main branch following the rules below:
+
+| Number of commits in the pull request | Main Branch Commit Title                                                                   | Main Branch Commit Description                                               |
+| ------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
+| Single commit                         | The title of the commit message for the single commit, followed by the pull request number | The body text of the commit message for the single commit                    |
+| More than one commit                  | The pull request title, followed by the pull request number                                | A list of the commit messages for all of the squashed commits, in date order |
+
+You can read more about this in the official
+[GitHub docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#merge-message-for-a-squash-merge).
+This plugin hijacks semantic-release flow and replaces the commits list with the one that respects these rules
+into the mix.
 
 ### Pull Request strategy (`{strategy: 'pull-request'}`)
 
@@ -66,3 +75,7 @@ The pull request number. In the context of GitHub actions, it is achievable as `
 
 Repository path, for example `n0th1ng-else/semantic-release-pr-analyzer`. For GitHub actions workflow it is
 set automatically.
+
+## Examples
+
+##### You can see the sample configuration in the [examples folder](https://github.com/n0th1ng-else/semantic-release-pr-analyzer/tree/main/examples).

examples/release.config.js

@@ -0,0 +1,22 @@
+const getConfig = (runInPRContext) => {
+  // In the pull-request action we only use semantic-release-pr-analyzer plugin
+  if (runInPRContext) {
+    return {
+      plugins: ["semantic-release-pr-analyzer"],
+    };
+  }
+
+  // Default configuration for the real release workflow
+  return {
+    plugins: [
+      "@semantic-release/commit-analyzer",
+      "@semantic-release/release-notes-generator",
+      "@semantic-release/npm",
+      "@semantic-release/github",
+    ],
+  };
+};
+
+const runInPRContext = Boolean(process.env.GITHUB_PR_NUMBER);
+
+module.exports = getConfig(runInPRContext);

src/utils.js

@@ -81,7 +81,7 @@ const STRATEGY = {
   StrictPullRequest: "strict-pull-request",
 };
 
-const getCommit = async (strategy, commits) => {
+const getRawCommit = async (strategy, commits) => {
   switch (strategy) {
     case STRATEGY.Github:
       return getGithubStrategyCommit(commits);
@@ -94,6 +94,15 @@ const getCommit = async (strategy, commits) => {
   }
 };
 
+const getCommit = async (strategy, commits) => {
+  /**
+   * TODO add pull-request number to the commit title.
+   * This does not affect the expected version.
+   * Just for consistency with GitHub.
+   */
+  return getRawCommit(strategy, commits);
+};
+
 const validateStrategy = (strategy) => {
   if (!strategy) {
     return STRATEGY.Github;