Add a configuration boolean switch "enabled" to enable or disable the current dependabot actions for one repository

[SEWeiTung]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

Refs: dependabot/feedback#216

From the previous discussion (sorry I didn't find related issues in the current issue list). We know that we can only disable dependabot for all repositories, it would be better if we can add a boolean switch through which we can decide whether the current config file can be "applied" or not for the dependabot actions. Something like this following (Take "enabled" as a switch example, if you miss writing it, the default means "true"):

version: 2
enabled: false ## This will enable/disable the current dependabot or not, missing it means "true" 
               ## UNLESS you set it "false" exclipitly
updates:

  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  # Maintain dependencies for npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  # Maintain dependencies for Composer
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"

Ignore me if there're such related issues or has been fixed anyway....Without such settings, we have to remove the file and re-add it later.

[yeikel]

You can disable dependabot updates from the repository settings. Have you considered that?

[yeikel]

When the file is present, you can disable it:

Or Enable it after disabling it :

When the file is missing, you'll see "Configure"

[jeffwidman]

Adding a way to enable/disable Dependabot version updates w/o having to completely remove the config file is a reasonable feature request.

A few thoughts:

1. The Disable button from @yeikel 's screenshot is from a forked repo. See https://github.blog/changelog/2022-11-07-dependabot-pull-requests-off-by-default-for-forks/ for details.
2. A teammate mentioned he thinks there's also a button like this on the organization settings page in GitHub Enterprise Server, to allow the organization admin to enable/disable version updates. AFAICT, it does not show on GitHub cloud at the org level. I'm don't know the historical context of why it shows only on GHES and not Cloud. Regardless since it's an org-level setting rather than a repo-level setting it doesn't solve the problem on a per-repo basis.
3. Re: whether we should expose a UI Disable button vs a global enable: true key (defaulting to true) in the config file... Currently there's some ambiguity on when a configuration option gets handled in the UI vs the config file... Today both are only used by GitHub service, but we've discussed the idea of trying to make dependabot.yml schema supported in a more open source manner... for example, if we were to add more support to parsing it in the CLI (subcommand to validate dependabot.yml file cli#59 for example). Obviously if it were a UI button, that's always going to be specific to the GitHub Dependabot service. I don't know what the future holds there, but we're aware there's ambiguity and something that over time we'd like to be more clear / consistent on what configs go where. cc @carogalvin for visibility.
4. For now, the obvious workaround for enabling/disable w/o removing the file is to comment/uncomment the file contents.

TBH, I'm not sure we'll ever ship this because it's a relatively uncommon feature request, and the workaround of commenting/uncommenting code seems straightforward. But we can leave it open for a while and monitor the 👍 to see how much user demand there is for this.

[yeikel]

@jeffwidman

1. The `Disable` button from @yeikel 's screenshot is from the organization settings page in GitHub Enterprise Server, to allow the organization admin to enable/disable version updates. AFAICT, it does not show on GitHub cloud at the org level. I'm don't know the historical context of why it shows only on GHES and not Cloud. Regardless since it's an org-level setting rather than a repo-level setting it doesn't solve the problem on a per-repo basis.

I do not believe that this is correct as I am able to see it in Github.com under my profile

When disabled from that settings page, it then asks the user to enable it from the insights page

[jeffwidman]

LOL! Now I'm the one going back and forth with you trying to figure this out. 😁

@yeikel You're right, what's actually happening in your screenshot is this is a fork!! 🎉

See the screenshot here:
https://github.blog/changelog/2022-11-07-dependabot-pull-requests-off-by-default-for-forks/

I think there's also a GHES related feature at the org level, although I don't have a GHES instance available right now for me to test.

I edited my post above to reflect this.

[yeikel]

LOL! Now I'm the one going back and forth with you trying to figure this out. 😁

@yeikel You're right, what's actually happening in your screenshot is this is a fork!! 🎉

See the screenshot here: https://github.blog/changelog/2022-11-07-dependabot-pull-requests-off-by-default-for-forks/

I think there's also a GHES related feature at the org level, although I don't have a GHES instance available right now for me to test.

That makes sense, and I can confirm it. When the repo is not a fork it just shows "configure"

Maybe this should be available for all repos even if they are not forks?

Sorry for the confusion. I was not aware of this distinction

[SEWeiTung]

Thank you @yeikel and @jeffwidman for your long time to follow this issue, AFAIK：

whether we should expose a UI Disable button vs a global enable: true key (defaulting to true) in the config file... Currently there's some ambiguity on when a configuration option gets handled in the UI vs the config file.

Why not make them "sync"? I mean you can both set "enabled" or "disabled" through either file or UI.

A teammate mentioned he thinks there's also a button like this on the organization settings page in GitHub Enterprise Server, to allow the organization admin to enable/disable version updates. AFAICT, it does not show on GitHub cloud at the org level. I'm don't know the historical context of why it shows only on GHES and not Cloud. Regardless since it's an org-level setting rather than a repo-level setting it doesn't solve the problem on a per-repo basis.

If for this case, is there any files' setting for the organization? If we have it, you can also add "enable"/"disable" for us to set both in files or UI's settings.

[SEWeiTung]

TBH, I'm not sure we'll ever ship this because it's a relatively uncommon feature request, and the workaround of commenting/uncommenting code seems straightforward. But we can leave it open for a while and monitor the 👍 to see how much user demand there is for this.

Thank you, in fact I this won'be so difficult:)

[jeffwidman]

A teammate pointed out that you can also disable version updates via the config file setting open-pull-requests-limit: 0 - relevant docs.

That won't disable security updates, but security updates can already be enabled/disabled from within the UI.

I expect this is probably all that we'd ship given that it works and there's not much demand for this so we're unlikely to invest further effort in adding a new config, so I'd like to close... will this workaround suffice for you @MaledongGit?

[SEWeiTung]

OK, since we have this settings, I closed it :)