Having issues creating PR on a server that is not github.com

[mattinger]

My definitions is as follows. The repository was checked out from our enterprise github server (not github.com), so I know there's connectivity.

      - name: commit-and-push-with-pr
        uses: peter-evans/create-pull-request@v5
        if: ${{ inputs.create-pull-request }}
        with:
          token: ${{ steps.set-github-env.outputs.github_token }}
          path: code
          add-paths: "${{ inputs.resource-path }}/**/${{ inputs.localizable-strings-filename }} ${{ inputs.localizable-string-path }}/${{ inputs.localizable-swift-filename}}"
          base: main
          branch: ${{ inputs.commit-branch }}
          commit-message: 'Sync ${{ github.workflow }} strings from S3'
          title: 'CMS Strings update: ${{ github.workflow }}'
          body: 'Sync ${{ github.workflow }} strings from S3'

I've validated that GITHUB_SERVER_URL is correct:

env:
    GITHUB_SERVER_URL: https://github.xxxxx.com/    

Yet when it comes time to push the PR it's failing with this message:

usr/bin/git config --local --get remote.origin.url
  https://github.xxxxx.com/org/repo
  Error: The format of 'https://github.xxxxx.com/org/repo' is not a valid GitHub repository URL

Based on looking at utils.js, it should be picking up the GITHUB_SERVER_URL variable and validating the local git config against that, but for whatever reason it doesn't seem to working correctly.

The same workflow works on github.com repositories, and i can commit using stefanzweifel/git-auto-commit-action@v4 for cases where the user doesn't want a PR created, so it's not a permissions issue.

[peter-evans]

Hi @mattinger

I think the issue is the trailing / on the server URL. Please try this:

env:
    GITHUB_SERVER_URL: https://github.xxxxx.com

If this is the problem then I'll add a fix to remove trailing slashes.

[mattinger]

I double checked, and we are not using a trailing slash:

      - name: set-github-env
        id: set-github-env
        run: |
          github_token=...
          github_server=${{ inputs.is-ghec && 'https://github.com' || 'https://github.xxxxx.com' }}
          echo "github_token=$github_token" >> $GITHUB_OUTPUT
          echo "github_server=$github_server" >> $GITHUB_OUTPUT

      - name: git-pull
        uses: actions/checkout@v3
        with:
          repository: ${{ inputs.repository }}
          submodules: false
          token: ${{ steps.set-github-env.outputs.github_token }}
          github-server-url: ${{ steps.set-github-env.outputs.github_server }}
          fetch-depth: 1
          ref: main
          path: code

I will try directly setting the environment variable on the commit-and-push-with-pr task tomorrow and report back, but i would expect that to behave exactly the same as the github-server-url parameter on the task itself.

[mattinger]

Even with the env set directly, it is still failing with the same error:

env:
    GITHUB_SERVER_URL: https://github.xxxxx.com
/usr/bin/docker exec  ff8985654e26e352559a497a935082ba3f3dc8ac85f239defdc7bafcf275902c sh -c "cat /etc/*release | grep ^ID"
Prepare git configuration
Determining the base and head repositories
  /usr/bin/git config --local --get remote.origin.url
  https://github.xxxxx.com/org/repo
  Error: The format of 'https://github.xxxxx.com/org/repo' is not a valid GitHub

Note that there's no / at the end of the env variable.

[mattinger]

I'm guessing maybe this is a scoping issue @peter-evans ? Is process.env actually reading from the env block of the action, or is that a higher level thing that's set by the action itself? Because i'm actually executing this action on one server, and pushing a commit to another.

[peter-evans]

My guess is that GITHUB_SERVER_URL is not getting set correctly, so the action just uses the default, https://github.com. It would be helpful to see your entire workflow to understand this better.

Are you setting the env on the action like this? If not, please try it.

      - name: commit-and-push-with-pr
        uses: peter-evans/create-pull-request@v5
        if: ${{ inputs.create-pull-request }}
        env:
          GITHUB_SERVER_URL: https://github.xxxxx.com
        with:
          token: ${{ steps.set-github-env.outputs.github_token }}
          path: code
          add-paths: "${{ inputs.resource-path }}/**/${{ inputs.localizable-strings-filename }} ${{ inputs.localizable-string-path }}/${{ inputs.localizable-swift-filename}}"
          base: main
          branch: ${{ inputs.commit-branch }}
          commit-message: 'Sync ${{ github.workflow }} strings from S3'
          title: 'CMS Strings update: ${{ github.workflow }}'
          body: 'Sync ${{ github.workflow }} strings from S3'

[mattinger]

Yes i'm setting it like that, though i'm using the output from another step:

      - name: set-github-env
        id: set-github-env
        run: |
          github_token=${{ inputs.is-ghec && secrets.SVC_SERVICEACC_GHEC_TOKEN || secrets.SVC_SERVICEACC_GHES_TOKEN }}
          github_server=${{ inputs.is-ghec && 'https://github.com' || 'https://github.xxxxx.com' }}
          echo "github_token=$github_token" >> $GITHUB_OUTPUT
          echo "github_server=$github_server" >> $GITHUB_OUTPUT

      - name: commit-and-push-with-pr
        uses: peter-evans/create-pull-request@v5
        if: ${{ inputs.create-pull-request }}
        env:
          GITHUB_SERVER_URL: ${{ steps.set-github-env.outputs.github_server }}
        with:
          token: ${{ steps.set-github-env.outputs.github_token }}
          path: code
          add-paths: "${{ inputs.resource-path }}/**/${{ inputs.localizable-strings-filename }} ${{ inputs.localizable-string-path }}/${{ inputs.localizable-swift-filename}}"
          base: main
          branch: ${{ inputs.commit-branch }}
          commit-message: 'Sync ${{ github.workflow }} strings from S3'
          title: 'CMS Strings update: ${{ github.workflow }}'
          body: 'Sync ${{ github.workflow }} strings from S3'

As i said, is suspect that the process scope that's getting used in utils.js is set by the github actions runner, not by the task's env block. I'm going to attempt to write a quick and dirty action to see if this theory is correct.

[mattinger]

It seems indeed that using the "env" black on the action DOES NOT override GITHUB_SERVER_URL, which i assume is set by github actions itself. I think perhaps this action might benefit from a separate parameter, like the checkout action has:

          github-server-url: ${{ steps.set-github-env.outputs.github_server }}

I assume the same would be true for GITHUB_API_URL as well, that it might need it's own parameter since it's generally set in the same way I think as the server url.

[peter-evans]

Ah, I think I understand what you are trying doing now. Are you running this workflow on GitHub's hosted servers, but trying to create a PR against a repo hosted in GHE?

[mattinger]

@peter-evans That's exactly correct. We're facilitating a process that pulls strings files from our CMS and updates the code repositories. We made it optional to automatically create a PR, which is where your action comes in. We're in a transition phase where some of our repos are still in GHES, but we're moving towards GHEC. So we'd like these workflows to work for both cases.

We're pulling code down from the repository with the actions/checkout@v3 action, passing it an explicit token and github-server-url parameters.

Then in the case where we don't want a PR, we're using stefanzweifel/git-auto-commit-action@v4, which uses the credentials stored with the checkout.

I think that it would be necessary to add the server-url, and token parameters (and possibly the api url if needed) to the create-pull-request task to allow it to work in this way.

[peter-evans]

@mattinger I'm thinking about the best way to support this kind of edge case.

Please could you let me know the correct GITHUB_API_URLs for GHES and GHEC? I just need an example to understand if I can infer what the correct URL should be. Perhaps GHEC is https://api.github.xxxxx.com? Does GHES follow the same pattern but with a custom domain?

[mattinger]

@peter-evans I think it differs from installation to installation, but on ours it's at https://github.xxxxx.com/api/v3. The public github server is at https://api.github.com i believe.

I would say that you should maybe provide inputs for both of these things, and default them to $GITHUB_SERVER_URL and $GITHUB_API_URL environment variables. I'm not really sure you need to infer them.

[peter-evans]

@mattinger I've realised that the way I'm using these environment variables doesn't make sense for use cases where the action is having to work across different GitHub products. So I would like to change how it works and make sure I can correctly support these cases. Inferring the values is my preferred approach because it reduces the amount of support work I need to do in future. There are users of this action who are not as technical as you and will have trouble figuring out the correct values without me helping them. I also don't like to add inputs to the action interface unless I really need to, in order to prevent it becoming bloated and complicated to configure.

The server URL is easy to infer, I just need to figure out the API url. This is what I understand so far:

GHES: https://my-ghes-server.com/api/v3
GHEC: ???
Github (non-enterprise): https://api.github.com

My guess is that GHEC is also https://api.github.com, but I would like to double check and make sure.

Please could you help me confirm the correct value for GITHUB_API_URL on GHEC. One way to check would just be to run a workflow in a repository that you have in GitHub enterprise cloud with a step to echo $GITHUB_API_URL. Would really appreciate it if you could check that for me. It saves me having to sign up to GHEC to check myself! 😄

[bonzofenix]

I hitted the same issue, usually the api pattern for enterprise github tends to be as follow:https://github.XXXXXX/api/v3@peter-evans

[peter-evans]

@mattinger, @bonzofenix,

I found some time to work on this and I've implemented logic to infer the URLs from the base repository's remote URL. This means it will use the URLs associated with the target repository, not where the workflow is executing.

This feature is now added to the v6 release candidate. It would be very helpful if you could try this version of the action and let me know if it works for you.

You can use it like this:

      - uses: peter-evans/create-pull-request@v6-rc

I'll be releasing v6 at some point in the near future.

[peter-evans]

I've now released v6. Thanks for your patience.