-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GHE Support #46
Comments
Hello @cb80, Please try out a development version |
@anton-yurchenko Amazing! The release is created. Only the asset upload fails:
I repeated the action to check if this is some kind of race and got this:
|
@cb80, I have updated the dev version to use a server URL for uploads instead of an API URL. Please re-run. Provide an output, as before, with an addition of an output of - name: Print EnvVars
run: printenv Have you customized instance endpoints, like Base URL / API URL* / Uploads URL, or are those default? Are you able to retrieve those through a server configuration? (we hope to be able to catch those from build env.vars) Regarding the second failure, this is because a release already exists: |
@anton-yurchenko I am not sure if the endpoints are customized. I am consuming the GHE instance in my company. But I can for sure ask for such details, if the env vars don't give us a clue. I am not sure if we have this These are the raw logs:
|
Thanks @cb80 I am not sure where The issue seems to be the following: I will raise a support ticket, maybe there are some differences between the public/private GitHub. |
Hello @anton-yurchenko I went back to the basics and used curl to successfully do the steps which went fine. The creation of a release returns the
There is an additional Here are the details of the tests with curl:
|
Thanks, @cb80, this is an important piece of information. So according to this, the initial approach was correct and two environmental variables should be used for client authentication. I have built another version with upgraded dependencies, added some debug logs, set the client to use two URLs again (when we observed that Please run it and provide the output as before. |
Hi @anton-yurchenko, here we go:
Do I have to approach our GHE admins? |
Thanks, @cb80 Can you try the same with different, simpler assets, like |
first of all thanks for your amazing support! I have created a ticket for our GHE admins to check where this And as you proposed I tried with
|
With pleasure 😉 @cb80
This will be helpful! |
I got the following answer from my GHE admins I can confirm this:
They also wrote Can we somehow debug the requests/responses? |
You may set a
|
fyi - I used
|
Thanks, @cb80 Action is configured according to a GHE Environment:
Moreover, a GHE API returns an
(Precisely this: I believe the root cause is a DNS CNAME Update: reply from GitHub support:
|
@anton-yurchenko |
I am certain that our GHE instance creates a token without the needed permissions. I mean using a different token than the auto generated one worked fine. So I guess your changes to support GitHub enterprise were successful. |
Great news @cb80! I am leaving that Issue open until a GHE support is released as a part of an upcoming Thanks for your help! |
@cb80 did you ever get an answer from github support on why |
@stevenh That's a long time ago :-) and no, I haven't received a good answer. However, there seem to be many ways to restrict the permissions of the token. Luckily there is some documentation available which may help you: |
Thanks for that, I will have a look. I've raised a support ticket to see if we can't get to the bottom the difference behind github.com and enterprise versions. Will report back if we get a solution. |
So it is a bug and will be fixed, here's the response from github support we got this morning:
So until GitHub Enterprise 3.5 is release we'll need to keep using personal access tokens. |
Thanks @stevenh 👑 |
Hello Anton Yurchenko
Description
We'd like to use git-release in a GitHub enterprise setup where we run our own github instance. We get the following output:
In the last line, you see that it tries to connect to github.com and not to the github enterprise instance.
The above is based on the following yaml:
If it is ok for you we are willing to invest into this with a little bit of guidance.
The text was updated successfully, but these errors were encountered: