Dependabot on Actions

[carlincherry]

Select Topic Area

Product Feedback

Body

About

Starting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot as an Actions workflow. This capability already exists for GitHub Enterprise Server (GHES) users and no further action is required enable Dependabot on Actions. This is the start of an effort to consolidate Dependabot's compute platform to Actions, with further migration plans to be announced in the coming months. 👀

Why choose to run Dependabot as an Actions workflow today?

Enabling Dependabot on Actions will yield performance benefits like faster Dependabot runs and increased visibility into errors to manually detect and troubleshoot failed runs. Actions APIs and webhooks will also be able to detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines. 🏁

Self-hosted runners, larger GitHub-hosted runners, and actions runner control (ARC) 🏃 will be supported in early May 2024; stay tuned for more.

Will this count towards Actions minutes or costs?

There will be no change or impact to the Dependabot functionality, and there will be no impact to billed Actions minutes (i.e. Dependabot runs are still free). :free

Let us know what you think!

Have you used Dependabot on Actions? What do you think?

Links to learn more:

Changelog
Automating Dependabot with GitHub Actions

[steveoh]

Will we be able to have a more flexible schedule on dbot pr's moving to actions? We'd like to run quarterly whereas monthly is the longest duration available in the configuration.

[carlincherry]

Unfortunately scheduling capability doesn't change as a result of this feature shipping. I've made note of your feedback for future feature prioritization though!

[steveoh]

Ok does migrating to the action infrastructure change the user experience?

I noticed in the docs that the examples were running dbot on pull request. That isn't how we use dependabot now. It runs automagically every month based on the yml file. Is pull request the trigger moving forward or will dbot still read the dependabot.yml configuration and get triggered since we don't schedule it with action syntax...

schedule: 
  - cron: ''

[carlincherry]

There is no change to the UX (besides faster runs and increased visibility that come for free as part of running on Actions. should still read your dependabot.yml configuration as it does today 😸

[jeffwidman]

This feature request is already tracked here, you may want to subscribe for updates:

• schedule.interval support cron expressions dependabot/dependabot-core#6339

[KexyBiscuit]

Is this feature available for everyone now? I can't see the "Dependabot on GitHub Actions Runners" setting in neither my own repositories nor my organizations'.

[KexyBiscuit]

The setting is available for me now.

[ruudk]

Does this mean that Dependabot can now access the secrets normally available for Actions Workflows? So that we no longer have to duplicate certain secrets in the dedicated Dependabot Secrets page?

[carlincherry]

This feature doesn't change the secrets accessibility for Dependabot!

[hfhbd]

Do you also plan to release a GitHub Action to run dependabot in your own workflows? https://github.com/github/dependabot-action is published but according to the docs, not usable.

This will also enable you to adjust the scheduler to finally run on weekends too, and to start the bot from mobile (using workflow-dispatch).

[andyleejordan]

Can't see how to file a bug with you guys but I managed to break Dependabot with my project. I enabled Dependabot on Actions and it crashes with:

Unhandled exception: System.ArgumentException: An item with the same key has already been added. Key: Microsoft.PowerShell.SDK
   at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at System.Linq.Enumerable.ToDictionary[TSource,TKey](IEnumerable`1 source, Func`2 keySelector, IEqualityComparer`1 comparer)
   at NuGetUpdater.Core.Discover.SdkProjectDiscovery.DiscoverAsync(String repoRootPath, String workspacePath, String projectPath, Logger logger) in /opt/nuget/lib/NuGetUpdater/NuGetUpdater.Core/Discover/SdkProjectDiscovery.cs:line 32

I believe it's trying to re-add that key because it is indeed a value specified multiple times in my .csproj file (but conditionally, a condition that Dependabot doesn't understand and isn't accounting for):

  <!-- PowerShell 7.4.x -->
  <ItemGroup Condition=" '$(TargetFramework)' == 'net8.0' ">
      <PackageReference Include="Microsoft.PowerShell.SDK" Version="7.4.1" />
  </ItemGroup>

  <!-- PowerShell 7.3.x -->
  <ItemGroup Condition=" '$(TargetFramework)' == 'net7.0' ">
      <PackageReference Include="Microsoft.PowerShell.SDK" Version="7.3.11" />
  </ItemGroup>

  <!-- PowerShell 7.2.x -->
  <ItemGroup Condition=" '$(TargetFramework)' == 'net6.0' ">
    <PackageReference Include="Microsoft.PowerShell.SDK" Version="7.2.18" />
  </ItemGroup>

Here's a link to the run: https://github.com/PowerShell/PowerShellEditorServices/actions/runs/8842186132/job/24280433435

After that crash it claims it found no matching dependencies in my two configured groups (because it never finished analyzing) and then exits with sucess 🙃

[jeffwidman]

Here's how to file bug reports: https://github.com/dependabot/dependabot-core/?tab=readme-ov-file#reporting-issues-and-feature-requests

[renefritze]

Could you clarify on how to select larger runners for dependabot to run on?
It's mentioned but I see no way to actually do it?

[renefritze]

Interesting, thanks @larsnystrom. How did you figure that out? Guess?

[larsnystrom]

I took a leap of faith and enabled running dependabot on github actions. I saw the workflows being scheduled in the "Actions" tab on my repo, but they were all yellow forever. I opened the log for one of the jobs and saw it was waiting for a runner with the dependabot label. So I guess you could call it trial and error!

[carlincherry]

Weird question -- are you also using self-hosted runners @larsnystrom?

[larsnystrom]

Weird question -- are you also using self-hosted runners @larsnystrom?

Not at all, yes I'm also using self-hosted runners!

[carlincherry]

⬆️ to that end we tested this with our engineers today, the best way to assign a larger GitHub hosted runner for Dependabot is:

1. Prework to set up your org with larger GitHub hosted runners
2. Call your larger GitHub hosted runner dependabot and/or add the label dependabot to the runner you want the Dependabot workflow to run on
3. Confusing piece here - to enable larger GitHub hosted runners, you also have to opt in the repo (or org) to self-hosted runners
4. Future Dependabot job / jobs will run on the larger GitHub hosted runner with the dependabot label

[Flasheh]

Hey!

I'm excited for this new feature but came across an issue while testing.

Are there any plans to make the dependabot label configurable so we can target specific runners?

I'n currently working in a Github Enterprise environment which has a set of shared enterprise-level runners across all organisations that have a dependabot label assigned to them. However within our organisation we host our own set of runners using ARC. Currently I do not see a way to target only our organisation-level runners.

[carlincherry]

Hi! To confirm is your end goal to only target specific runners amongst a fleet of runners all of which have the dependabot label?

[Flasheh]

Yes that's correct. As not all runners have network access to our internal artifact repository which dependabot would need.
If it was possible to use a custom label to match runners for dependabot within our organisation then that would be a viable solution for us.