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