Failure to get associated PRs for forked repo

[joe-p]

When running semantic-release with this plugin in a forked repo, the success step will fail because the PR doesn't exist in the repositoryUrl.

For example, given a fork of originalOrg/some-repo: orgWithFork/some-repo, the plugin will get the associated PRs for the release, but then try to fetch them from orgWithFork repo instead of the upstream originalOrg

     url: 'https://api.github.com/repos/orgWithFork/some-repo/pulls/55/commits',
    status: 404,

Here's the failing workflow run: https://github.com/joe-p/algokit-core/actions/runs/14618441013/job/41012357613

[babblebey]

If I may ask, was the release successful?

i.e. did you get a tag, a release note etc???

[joe-p]

Yeah the release was successful. Here is the full workflow run: https://github.com/joe-p/algokit-core/actions/runs/14618441013/job/41012357613

It just failed on the success step after release. The main problem is that this results in the workflow to fail

Edit: I should also mention that this was the first release in the forked repo, thus why it was looking for upstream commits/PRs. I imagine this would also be a problem with any forked repo that regularly pulls commits from upstream

[babblebey]

Thank you @joe-p,

I found that the reason why the success step failed in because of associatedPR/Issues that wasn't found on your fork.

semantic-release looks for Issues and PRs that are related to a PR and Commits in a release via PR description or the commit body, it does this by parsing out issue/PR number #000 that follows the github relation keywords (Fixes, Closes etc.); it fetches the issue in attempt to write a success comment on the issue or PR.

This PR/Issue was not found in your fork because they belong to the parent repo (apparently you do not have any issue of PR with number #55 now do you!? 😉).

Edit: I should also mention that this was the first release in the forked repo, thus why it was looking for upstream commits/PRs. I imagine this would also be a problem with any forked repo that regularly pulls commits from upstream

Yea, this will be some wow use-case of semantic-release to me.... Get in here @jedwards1211 😉; How would you suggest we can handle this kinda case; is this is a thing to do release on a fork with ones change and pull changes from upstream too?? 🤔

[joe-p]

There's a couple of scenarios where one could encounter this:

• forked repo and performing initial release with commits from upstream that reference upstream PRs
• forked repo and performing release after merging in upstream commits that reference upstream PRs
• Migrated/copied git repo from another remote to GitHub (i.e. GitLab -> GitHub)
• Maybe more???

I think because of the various scenarios it would make sense to emit a warning when a PR cannot be linked but not completely fail. Perhaps there can be some recovery mechanisms in place (i.e. check if the current repo is a fork and then check upstream), but even then you run into scenarios where it may be hard to find the PR with 100% certainty.

[jedwards1211]

@joe-p just making sure I understand, your goal here is to release your fork of the code under a different package name, right? But also periodically merge changes from the original package and also release these under your forked package name? (I've done this before to avoid waiting for bugfixes to get merged in a package)

In this case, theoretically you might want an error if you typo PR/issue numbers in your own commits that are supposed to reference PRs/issues in your fork, right?

The question is how to differentiate between the two. Maybe if we see that a commit exists in the upstream history (allowing the user to configure a different upstream remote name), then we ignore or warn about failure to find issues referenced in those commits.

[joe-p]

just making sure I understand, your goal here is to release your fork of the code under a different package name, right? But also periodically merge changes from the original package and also release these under your forked package name? (I've done this before to avoid waiting for bugfixes to get merged in a package)

This actually isn't a critical need for me. I encountered this bug when testing the CD for one repo in a fork so I could avoid test releases on upstream.

The question is how to differentiate between the two.

That's a great question. You also have the problem of a PR existing in both forks. Although I suppose you can check to see if that PR has the relevant commit.

Maybe it's best to have this configurable. Out of the box it could be a warn if the PR isn't found but have a option to fail?

Edit: Flipping the default probably makes sense: Default error, but have an option to just warn. I say that because working like this in a forked repo is probably pretty rare

[jedwards1211]

Yeah I think warning by default is risky because most users would never find out there were warnings and only later notice if semantic-release is failing to modify associated issues/PRs or there's a typo in the issue number. Maybe it's rare enough that it's not a big deal, but I think at least an option to warn makes sense. It would be less of an effort than figuring out which remotes a given commit came from

[ankush]

Faced similar/same issue. We are trying to release on main repo: frappe/erpnext@6b38654 https://github.com/frappe/erpnext/actions/runs/16776779573/job/47504621550

There's a fork with PR open for that same branch, it doesn't seem to be a serious PR but now release workflow breaks because of it 🥲 The code is trying to fetch PR #1 on parent org, which doesn't exist, so this does feel like buggy behavior to me.

Maybe a right fix here would be to ignore associated PRs from other org/users?

[babblebey]

Yea, thanks @ankush

It appears that the PR #1 was caught-up at thesame point as reported, and I figured that it is at the point where we try to confirm that the found associatedPR has commits related to the one it was discovered from.

Maybe a right fix here would be to ignore associated PRs from other org/users?

So we read relatedIssues and associatedPRs in releases from the body of commit messages and PR descriptions/body; So we already have measures in place that's ignoring the ones from other orgs. We use a parser that ensures checks for org/user and repo names is exactly as current repo and owner. If you can help me understand better what you mean by what you said...

There's a fork with PR open for that same branch, it doesn't seem to be a serious PR

... by maybe point me to the Pull Request that referenced this opened PR you speak, It'd help us better understand and reproduce this issue for a fix.

Though a quick fix would be to return a false value when we find this or any error in the operation from the point where we confirm PR relation to commit below...

github/lib/success.js

Lines 120 to 140 in 005c4e3

	const prs = await pFilter(uniqueAssociatedPRs, async ({ number }) => {
	const commits = await octokit.paginate(
	"GET /repos/{owner}/{repo}/pulls/{pull_number}/commits",
	{
	owner,
	repo,
	pull_number: number,
	},
	);
	const matchingCommit = commits.find(({ sha }) => shas.includes(sha));
	if (matchingCommit) return matchingCommit;
	const { data: pullRequest } = await octokit.request(
	"GET /repos/{owner}/{repo}/pulls/{pull_number}",
	{
	owner,
	repo,
	pull_number: number,
	},
	);
	return shas.includes(pullRequest.merge_commit_sha);

...but that feel like a patch-up if we don't understand how this PR crawled into the mix better in the first place.