@cschleiden any ETA or status on when this could be possible?

@thedaviddias No updates to share at this point, we are still figuring out the next set of priorities.

Thank you @cschleiden!

I'm about to on-board 300+ developers to GHES and would love to tell them "you can use this extension to mind your Actions activities directly in VSCode."

I'm member of a 20000+ user GHES instance and would also love to see some prioritization of this ticket.

This would also require a tiny change to the language server, which I proposed in actions/languageservices#43, to actually show all the relevant information

I implemented the necessary changes in #183, would be happy if someone could review 😄

x-posting my comment here:

#183 (comment)

Thank you for this. Unfortunately for full GHES support it's not just about authenticating and making calls to the right API base url. The biggest issue to solve is versioning.

Not every customer is running the latest GHES version. And the latest released GHES version does not always support the same features as github.com. So some APIs that the extension relies on might not be available on the connected GHES version. Or the GitHub Actions workflow schema that ships with the extension does not match the features supported by the connected GHES version.

Ideally, we detect the GHES version and select the correct feature set, but this requires more work across the language services and the extension itself.

We might be able to add what you're proposing here as something that's unsupported (but still available) but that requires some more discussion.

Any update on this? I can see the README now mentions it but it looks like that was a preemptive change. We have a large number of internal developers excited to use this extension with our 3.8 GHES instance.

I was able to connect to GHES, but I couldn't trigger workflow, and nothing happened when I clicked.

In our work environment we use GHES 3.8 and I was also able to connect, so it works... partially.
I'm using this extension only to track the status of my workflows and have the syntax highlighting and completion.

There is currently an issue when retrieving organization secrets for a repository while hovering over my actions code (showing Request textDocument/hover failed or Request textDocument/completion failed.

This is because GHES 3.8 doesn't support the most recent GitHub API yet and the List repository organization secrets endpoint is not available in 3.8.

This will change with GHES 3.9:

• REST API
  To provide API integrators a smooth migration path and time to update integrations after GitHub makes occasional breaking changes, the REST API now uses calendar-based versioning. GitHub Enterprise Server 3.9 provides version 2022-11-28 of the REST API. For more information, see "API Versions" in the REST API documentation.

Maybe this helps.

The Github authentication plugin allows to connect to priate instances of github enterprise
Please add a configuration field to allow to use private github instances

Thanks!

#12 (comment)

One note, after enabling GHES support, the actions that are sourced from our enterprise server are still linking to github.com when clicking Open action on GitHub in a workflow. I think if GHES is enabled then all of the Open action on GitHub buttons should also link to the configured instance of GHES.

One note, after enabling GHES support, the actions that are sourced from our enterprise server are still linking to github.com when clicking Open action on GitHub in a workflow. I think if GHES is enabled then all of the Open action on GitHub buttons should also link to the configured instance of GHES.

The same problem exists referencing reusable workflows. They reference github.com instead of our GHES instance.

Could some kind of override be added for the known named actions? The easiest way around this might be to just deploy global vs code settings to our users with a list of internal actions. Maybe a wildcard for an org name to just assume it exists and link to it based on a setting?

Could some kind of override be added for the known named actions? The easiest way around this might be to just deploy global vs code settings to our users with a list of internal actions. Maybe a wildcard for an org name to just assume it exists and link to it based on a setting?

Not sure what this is meant to solve; repositories hosted on GHES cannot access any actions from github.com, so there is no need to sometimes look up actions on the cloud, sometimes on GHES. All actions, including built-ins like "checkout", have to be available on that GHES instance (the built-ins are bundled with the server setup, so their version can be significantly different than on github.com!).
(At least this is true for the GHES instance I'm working with, maybe there's more to it...)

IMHO, the extension needs to determine the github instance the repository is hosted on, and stick with that for all workflows in that repo. And actually it should already know it, as it correctly lists workflows, opens logs on GHES, etc., so it knows where that workflow is hosted. It just needs to connect that knowledge to opening actions.

Not sure what this is meant to solve; repositories hosted on GHES cannot access any actions from github.com, so there is no need to sometimes look up actions on the cloud, sometimes on GHES. All actions, including built-ins like "checkout", have to be available on that GHES instance (the built-ins are bundled with the server setup, so their version can be significantly different than on github.com!).
(At least this is true for the GHES instance I'm working with, maybe there's more to it...)

It is the case that the GHES instance comes with an actions org that has a lot of built-in actions. Though I may be missing something, I believe GitHub Connect is the optional feature that lets you use actions from github.com: https://docs.github.com/en/enterprise-server@3.14/admin/managing-github-actions-for-your-enterprise/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect

It is the case that the GHES instance comes with an actions org that has a lot of built-in actions. Though I may be missing something, I believe GitHub Connect is the optional feature that lets you use actions from github.com: https://docs.github.com/en/enterprise-server@3.14/admin/managing-github-actions-for-your-enterprise/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect

Thank you, I did not know about this, we use the actions-sync tool mentioned in that same doc. I'm now glad I added that disclaimer in my comment 😆
That explains the need to at least fall back on github.com if the action cannot be found on the GHES instance... The extension could probably check whether GitHub Connect is enabled, but that sounds overkill to me.

The extension could probably check whether GitHub Connect is enabled, but that sounds overkill to me.

I've had to explain this limitation to multiple folks asking my team why they were seeing errors in VSCode in the past two weeks, so it feels like missing behavior to me :)