Issue:
In our setup, we have tags, changelog, released, and deployment occur when a PR is closed, and the state is merged=true. To do this, the GitHub actions make a new PR and output the changelog from GitHub-tag-action to the CHANGELOG.md. Then after merging the PR ( which skips a second changelog run), a release is created using the same changelog output from this module.
This works great; however, at concurrency, we have noticed the following issues where a commit in Branch B is in the past compared to the tag ref that was generated.
┌───────────────────┐
│ Branch A ├────────────────►Branch autochangelog_A
│ Commit 0000001│ PR1 │
└───────────────────┘ │
│
┌─────────────┐ ▼ PR3 v0.0.3
│ Base Branch ├────────────────────────────────────────────────────────────────────────────────────────────────── HEAD
└─────────────┘ v0.0.2 ▲
v0.0.1 ┌───────────────────┐ │
│ Branch B ├─────────────────────────────────────────►Branch autochangelog_B
│ Commit 0000002│ PR2
└───────────────────┘
Cause:
When looking at this, I realized the context is that we are in a closed state. payload is a bit different. Rather than just having the base and head sha's, it also has a list of commits with their sha's and message. I can find commits from this branch when the API's compareCommits is not finding any commit.
Solution:
When a PR is closed, the context.payload.pull_request is undefined and instead has context.payload.commits available. Unlike when the PR is open, these are not just sha items or a URL to the commits but a list of the commit with all the values you would have usually gotten from compareCommits without worrying about the tag issues described above.
As a result, we get the following output after this patch :
We found 0 commits using classic compare!
We did not find enough commits, attempting to scan closed PR method.
We are in a closed PR context continuing.
We found 2 commits from the PR method.
After processing we are going to present 2 commits!
We found 2 commits to consider!
Analyzing commit: fix(file-b): removing B file
The release type for the commit is patch
Analyzing commit: Merge pull request #44 from dbmurphy/fooB
fix(file-b): removing B file
The commit should not trigger a release
Analysis of 2 commits complete: patch release
This will only fire if normal mode fails to find commits so it's only a backup method when before assuming there are not commits to compare, as we know PR's MUST have commits in them.
Issue: In our setup, we have tags, changelog, released, and deployment occur when a PR is closed, and the state is merged=true. To do this, the GitHub actions make a new PR and output the changelog from GitHub-tag-action to the CHANGELOG.md. Then after merging the PR ( which skips a second changelog run), a release is created using the same changelog output from this module.
This works great; however, at concurrency, we have noticed the following issues where a commit in Branch B is in the past compared to the tag ref that was generated.
Cause: When looking at this, I realized the context is that we are in a closed state. payload is a bit different. Rather than just having the base and head sha's, it also has a list of commits with their sha's and message. I can find commits from this branch when the API's compareCommits is not finding any commit.
Solution:
When a PR is closed, the
context.payload.pull_requestis undefined and instead hascontext.payload.commitsavailable. Unlike when the PR is open, these are not just sha items or a URL to the commits but a list of the commit with all the values you would have usually gotten from compareCommits without worrying about the tag issues described above.As a result, we get the following output after this patch :
This will only fire if normal mode fails to find commits so it's only a backup method when before assuming there are not commits to compare, as we know PR's MUST have commits in them.