You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Having issues creating PR on a server that is not github.com #2020
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.
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.
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.
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.
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.
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.
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:
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.
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?
@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.
@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?
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.
@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:
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! 😄
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.
Activity
peter-evans commentedon Jun 5, 2023
Hi @mattinger
I think the issue is the trailing
/on the server URL. Please try this:If this is the problem then I'll add a fix to remove trailing slashes.
mattinger commentedon Jun 5, 2023
I double checked, and we are not using a trailing slash:
I will try directly setting the environment variable on the
commit-and-push-with-prtask tomorrow and report back, but i would expect that to behave exactly the same as thegithub-server-urlparameter on the task itself.mattinger commentedon Jun 5, 2023
Even with the env set directly, it is still failing with the same error:
Note that there's no / at the end of the env variable.
mattinger commentedon Jun 5, 2023
I'm guessing maybe this is a scoping issue @peter-evans ? Is
process.envactually reading from theenvblock 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 commentedon Jun 6, 2023
My guess is that
GITHUB_SERVER_URLis 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.
mattinger commentedon Jun 6, 2023
Yes i'm setting it like that, though i'm using the output from another step:
As i said, is suspect that the
processscope that's getting used in utils.js is set by the github actions runner, not by the task'senvblock. I'm going to attempt to write a quick and dirty action to see if this theory is correct.mattinger commentedon Jun 6, 2023
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:
I assume the same would be true for
GITHUB_API_URLas 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 commentedon Jun 7, 2023
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 commentedon Jun 7, 2023
@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
tokenandgithub-server-urlparameters.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 commentedon Jun 9, 2023
@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 ishttps://api.github.xxxxx.com? Does GHES follow the same pattern but with a custom domain?mattinger commentedon Jun 10, 2023
@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 commentedon Jun 13, 2023
@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/v3GHEC: ???
Github (non-enterprise):
https://api.github.comMy 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_URLon 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 toecho $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 commentedon Oct 30, 2023
I hitted the same issue, usually the api pattern for enterprise github tends to be as follow:
https://github.XXXXXX/api/v3@peter-evanspeter-evans commentedon Dec 19, 2023
@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:
I'll be releasing
v6at some point in the near future.peter-evans commentedon Jan 31, 2024
I've now released
v6. Thanks for your patience.