PR creation failing due to fetch failing about create-pull-request

[peter-evans]

Correct. The repo URL is https://github.com/$ORG/$REPO, and the organisation is using self hosted runners.

I think it's unlikely that the "infer-urls" feature caused the issue then. 🤔
Just to confirm, it would be great if you could execute this on your self-hosted runner and let me know what the output is.

- run: echo $GITHUB_API_URL

[kierans]

> Run echo $GITHUB_API_URL
https://api.github.com/

[kierans]

@peter-evans I tried setting the https_proxy. Unless I’m doiong something wrong, the proxy isn’t the issue.

Run peter-evans/create-pull-request@v6
  with:
    base: main
    ...
 env:
    httpProxy: http://172.17.0.1:3128
    https_proxy: http://172.17.0.1:3128
    
Create or update the pull request
  Attempting creation of pull request
  Error: fetch failed

[peter-evans]

Not sure if this will fix it, but it's worth a shot. Please try this version of the action.

uses: peter-evans/create-pull-request@bump-proxy-agent

[peter-evans]

Hi @kierans

I need more information to understand what is happening here.

Things that would help:

• A complete workflow
• A more complete snippet of the logs
• A link to the run (if public)

[kierans]

@peter-evans Thanks for looking at this.

This issue is in the context of a corporate project. I’ve updated the description with more info about the workflow job. I’ve uploaded logs of the run. I’ve had to redact some of the logs, but I think there’s enough there for you to see what’s happening in the run. The GHA run is not public I so can’t give you the link.

[peter-evans]

Everything looks fine, so my guess is that this problem is caused by some issue with running on self-hosted. I think if you tried this on hosted (github.com) it would work. That could be a way you can narrow down the problem.

[kierans]

This was working with v5. Dependabot upgraded the action to v6. I’ve reverted back to v5

Looking at a comparison between v5 and v6 I’m wondering if the change to the way git fetch is invoked might be the cause? Maybe it’s a git version issue?

[peter-evans]

This was working with v5. Dependabot upgraded the action to v6. I’ve reverted back to v5

Can you confirm that it works now after reverting back. If that's the case I can try to narrow this down.

I’m wondering if the change to the way git fetch is invoked might be the cause?

Looking at the log, though, it's already past that point and created the PR branch successfully. The point where it fails is when it's calling the GitHub API to create the PR.

[peter-evans]

I think it's this change: main...infer-urls#diff-149194b9a050dce062d6db2902041d8d9b9c28245428d7435ed58a87fc25b3dc

I added a feature to infer the URLs of repositories so that PRs could be made across different GitHub platforms.

Are you using GHES or GHEC? It looks like the repo has a https://github.com/$repo URL, so perhaps not. Can you confirm your situation. The repo is hosted normally on github.com and you are using self-hosted runners?

This is the logic I added, which a suspect may not be working for your use case.

    if (githubServerHostname !== 'github.com') {
      options.baseUrl = `https://${githubServerHostname}/api/v3`
    } else {
      options.baseUrl = 'https://api.github.com'
    }

[kierans]

This was working with v5. Dependabot upgraded the action to v6. I’ve reverted back to v5

Can you confirm that it works now after reverting back. If that's the case I can try to narrow this down.

It is.

[kierans]

Are you using GHES or GHEC? It looks like the repo has a https://github.com/$repo URL, so perhaps not. Can you confirm your situation. The repo is hosted normally on github.com and you are using self-hosted runners?

Correct. The repo URL is https://github.com/$ORG/$REPO, and the organisation is using self hosted runners.

[peter-evans]

> Run echo $GITHUB_API_URL
https://api.github.com/

This is what I would expect, so I don't think the "infer-urls" feature is the problem.

Perhaps this is proxy related. From the log it looks like you are behind a proxy for https requests. Please try setting the proxy explicitly like this:
https://github.com/peter-evans/create-pull-request?tab=readme-ov-file#proxy-support

It's possible that a library I was using has updated and somehow no longer automatically captures your proxy settings.

[peter-evans]

The workflow you posted starts with jobs:. Please can you show me the full workflow. Are you setting any environment variables at the top?

Also, please could you confirm that when you test v6 there are no other changes to the workflow, you are literally just changing the version of the action.

I'm leaning towards this being a proxy handling connection issue due to some changes to a library I'm using, but I'll try to figure this out! 😄

[kierans]

The workflow you posted starts with jobs:. Please can you show me the full workflow. Are you setting any environment variables at the top?

I am not setting anything extra in the workflow.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - '**'
jobs:
  documentation:

...

The runner is setting the $http_proxy and $https_proxy env vars in the shell that the run is being run in.

As you can see from the logs the action is being run with https_proxy and httpProxy being set to a value

I’ve added the following step that creates the httpProxy var from the $https_proxy shell var to pass to the action ie:

 - name: Set up job
    run: |
        echo "httpProxy=${https_proxy}" >> $GITHUB_ENV

uses: peter-evans/create-pull-request@bump-proxy-agent
...
env:
    https_proxy: ${{ env.httpProxy }}

Also, please could you confirm that when you test v6 there are no other changes to the workflow, you are literally just changing the version of the action.

That is correct.

I'm leaning towards this being a proxy handling connection issue due to some changes to a library I'm using, but I'll try to figure this out! 😄

I’ve tried the bump-proxy-agent version and still getting “Fetch failed”.

Perhaps it’s worth trying to get more information from the error in the console to continue to aid the debugging efforts.

[peter-evans]

Perhaps it’s worth trying to get more information from the error in the console to continue to aid the debugging efforts.

Yes I think we need to try and narrow this down and make a minimal example that reproduces the problem. This must a rare edge case, because no other users have reported this (so far). This action is used a lot, so I would expect most issues to effect many users.

I'll have a think about how we can narrow this down.