Support private registries for github-actions

[martincostello]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

When using dependabot with GitHub Enterprise server where using Actions from github.com is disallowed, dependabot will raise pull requests to update actions to versions that are not available in the appliance.

As a concrete example, GitHub Enterprise Server 3.6 is bundled with actions/setup-dotnet v2 but the current latest version on github.com is v3.

Within GHES, dependabot will generate a pull request to bump a reference to v2 of this action to v3, which will then break because that version is not available in the appliance.

Configuring dependabot.yml to point to GHES for actions updates isn't possible as github-actions is not a supported value for the type property of a private registry under registries (docs).

At a minimum, dependabot should support private registries for github-actions so that enterprise-level actions can be correctly kept up-to-date.

Ideally, dependabot when run within GHES would be able to determine for itself whether public actions are allowed or not, and use the correct GitHub host to determine the latest actions versions that are available of its own accord without manual configuration.

[deivid-rodriguez]

Hei! Indeed github_actions is not allowed as a type, but Actions are backed by a git repository, so you should be able to configure a git source to do what you want.

Let me know how that works!

[martincostello]

The uses documentation doesn’t seem to state that a full GitHub host name can be specified ahead of the repo user|org/name value.

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsuses

That also seems like a lot of additional configuration to have to hardcode the URL of the GHES appliance itself running the jobs into every single step of every single workflow in the whole Enterprise when it otherwise Just Works™️ as a built-in feature.

[deivid-rodriguez]

Sorry, I didn't explain why I mean correctly. I meant that you should be able to configure a git registry for your GHES instance.

[Okeanos]

Yeah … I am firmly with @martincostello in spirit. A good user (developer) experience looks way different from is proposed here. The Git repository declaration may be useful as workaround for now but – within a GHES environment – having to constantly work around weird edge cases in Dependabot limitations (see for example #1884, #1959) is really frustrating. Especially because Dependabot is supposed to be a first party product as in "part of the GitHub experience".

[deivid-rodriguez]

Just trying to help here, apologies if my suggestions don't fulfill your expectations.

Please help me understand what's being requested here.

Is it to, instead of writing

registries:
  github-octocat:
    type: git
    url: <my-ghes-url>
    username: x-access-token
    password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

be able to write

registries:
  github-octocat:
    type: github-actions
    url: <my-ghes-url>
    username: x-access-token
    password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

?

[martincostello]

The built-in Dependabot integration for GHES already doesn't need to be configured with authentication for cloning repositories or raising pull requests, so I wouldn't expect to need to tell it how to authenticate with the GHES appliance itself and could discover for itself whether fetching GitHub Actions from the internet is allowed at all.

Ideally, something as minimal as this if Dependabot needs to be told it isn't running in the context of github.com, but given the first-party integration, I would expect it to be able to find out for itself that it wasn't running in "the" GitHub and act accordingly:

registries:
  github-octocat:
    type: github-actions
    url: https://github.corp.local

[deivid-rodriguez]

Ok!

I completely lack experience on GHES so let me check with the rest of the team and I'll get back 👍.

[Okeanos]

Just trying to help here, apologies if my suggestions don't fulfill your expectations.

I understand – and any workaround is better than none. I am terribly sorry about my comment being overly aggressive, it was not meant as an (personal) attack. I very much welcome any feedback here and thank you for attempting to provide a workaround.

[MoritzKeppler]

We tested exactly that, added a registry of type git and reference it in the updates section of package-ecosystem github-actions.
But it feels like the registry information is completely ignored. All I can see in the workflow logfile are calls to github.com but no calls to our GH Enterprise instance (GHE 3.5 i.e. we are using this dependabot version https://github.com/github/dependabot-action/blob/ghes-3.5/docker/containers.json). Has anybody successfully setup the workaround? Still wondering what we're doing wrong.
Thanks a lot!

[deivid-rodriguez]

Apparently the workaround has also recently regressed, as per #6140. So, no, you're not doing anything wrong, it's us.

I'll try find some time to look into this, sorry for the inconveniences!

[jeffwidman]

IIUC, you're wanting the GHES appliance to prefer itself as the source of the action. This was actually added in GHES 3.7 by #5469. However, we later discovered a bug which was fixed by #6512 and released last week. So if you fetch the latest version of the Dependabot action for your GHES instance, this should work as desired.

I'm going to close because I think this is now handled, but if you're still encountering problems even after upgrading please comment and we can re-open.

[MoritzKeppler]

Thanks a lot!
I made a quick attempt. Dependabot has made exactly the right calls to our enterprise instance and detected a necessary update. But nevertheless it fails... maybe just a misconfiguration on our side, haven't checked in detail

updater | INFO <job_4669> Updating ... from 1.0.0 to 1.0.1
updater | ERROR <job_4669> Error processing ... (RuntimeError)
updater | ERROR <job_4669> No files changed!
ERROR <job_4669> /home/dependabot/github_actions/lib/dependabot/github_actions/file_updater.rb:28:in `updated_dependency_files'

update: it seems to work when updating built-in actions that are synchronized to our GHE instance (e.g. actions/setup-java). But not when I reference an action that just exists in our instance.

[pavera]

@MoritzKeppler if you could provide a bit more info about the local only action? I'm trying to put together a list of gaps in our actions support so we can tackle them. Is this a reusable workflow or is it a full fledged action in a private repo? If you could provide a representative "uses" setting from the workflow for this action. Anonymized is fine, but having all of the path segments included in the real "uses" setting. We use a regex to find/parse the action names and I suspect the update is failing because this regex is too specific.

[MoritzKeppler]

Sure, it's a 'full fledged' action with two release "v1.0.0" and "v1.0.1"
The uses section in my test run looks like this:

 - uses: myactions/setup-kubectl@v1.0.0
        with:
          kube-config: ${{ secrets.KUBE_CONFIG }}
          version: v1.24.0