GITHUB_SERVER_URL does not preserve URI prefix

[Reverier-Xu]

Hi, I'm trying to deploy Gitea and setup its integrated runners which is compatible with GitHub Actions.

The git server is running under a uri prefix:

https://example.com/**service_prefix**/<USER>/<REPO>

I notice the code you implemented below:

// src/url-helper.ts
...
export function getFetchUrl(settings: IGitSourceSettings): string {
  assert.ok(
    settings.repositoryOwner,
    'settings.repositoryOwner must be defined'
  )
  assert.ok(settings.repositoryName, 'settings.repositoryName must be defined')
  const serviceUrl = getServerUrl(settings.githubServerUrl)
  const encodedOwner = encodeURIComponent(settings.repositoryOwner)
  const encodedName = encodeURIComponent(settings.repositoryName)
  if (settings.sshKey) {
    return `git@${serviceUrl.hostname}:${encodedOwner}/${encodedName}.git`
  }

  // "origin" is SCHEME://HOSTNAME[:PORT]
  return `${serviceUrl.origin}/${encodedOwner}/${encodedName}`
}
...

it seems that you just construct repo url with serviceUrl.origin, the uri prefix has been ignored.

Is there any particular reason for doing so? If not, I'd like to be able to make a pull request to change its behavior.

[frankli0324]

this could be useful not only on a custom deployment of git server+runner, consider the scenario when a project requires a repo hosted on another server, and needs to check that repo side by side

[apnorton]

Can confirm that PR #1305 worked for me in resolving the issue with a gitea instance and a service prefix; now just for it to be merged...

[joshmgross]

We're currently only prioritizing issues for GitHub Actions, which is the primary use case for all of our first-party actions. We don't test compatibility with third-party solutions and thus can't maintain or support any features created exclusively for those third-parties.

This action is open source so you're welcome to fork it and modify it however you wish to support these sort of scenarios.

[OdinVex]

We're currently only prioritizing issues for GitHub Actions, which is the primary use case for all of our first-party actions. We don't test compatibility with third-party solutions and thus can't maintain or support any features created exclusively for those third-parties.

This action is open source so you're welcome to fork it and modify it however you wish to support these sort of scenarios.

That's a rather lame and pathetic anti-competitive and anti-consumer attitude. This is why people are developing alternatives to GitHub, Microsoft ruins everything it touches. I bet some people still remember Embrace, Extend, Extinguish.

[apnorton]

@joshmgross Is it possible to reconsider? This issue will present a problem in any GitHub Enterprise setup where there is a further path following the domain (e.g. if an on-prem installation of GitHub enterprise was hosted behind a reverse proxy at devops.companyname[.]com/github/, this first-party github action will fail); it is not an issue limited to actions for third party solutions. (As far as I can tell from the docs, it is valid to host GitHub Enterprise behind a reverse proxy.)

edit to add: Or, alternatively, do you accept pull requests? I'd be happy to put in the effort to make this work, but I'm not sure if your invitation to fork was also one to contribute vs if this is only managed by official staff.

[OdinVex]

@joshmgross Is it possible to reconsider? This issue will present a problem in any GitHub Enterprise setup where there is a further path following the domain (e.g. if an on-prem installation of GitHub enterprise was hosted behind a reverse proxy at devops.companyname[.]com/github/, this first-party github action will fail); it is not an issue limited to actions for third party solutions. (As far as I can tell from the docs, it is valid to host GitHub Enterprise behind a reverse proxy.)

edit to add: Or, alternatively, do you accept pull requests? I'd be happy to put in the effort to make this work, but I'm not sure if your invitation to fork was also one to contribute vs if this is only managed by official staff.

Work was already done, they just don't want to play friendly with the FOSS community. It's about keeping FOSS-alternatives down. This is sort of a slant on EEE except to steer people to GitHub and away from FOSS if people can't write universally-acceptable Actions scripts, etc. Love the 'Microsoft <3 Linux' shtick. *eyeroll*

[andrewakim]

👋 Hey everyone - I'm a PM for Actions and just want to add to what @joshmgross said. We won't be able to prioritize it for now but we'll add it to our feature request backlog so that I can dig in to the GHES use cases at some point. In the interim, forking and modifying the action is probably the fastest way to get you what you need. Thanks!

[apnorton]

Sounds good; thanks for at least considering it. 🙂

[OdinVex]

I feel like snow has been blown up our ends.