GitHub-hosted runners now support up to 1000 concurrent jobs for our 4 – 64 vCPU runners, enhancing their capability to handle large-scale CI/CD workloads.
Our runners are designed to automatically scale to meet your needs. The concurrency limit feature allows users to specify the maximum number of jobs that can run simultaneously to execute Actions workflows. Previously capped at 250, we've made backend improvements to now support a maximum of 1000 concurrent jobs for runners within the 4-64 vCPU range for Windows and Linux operating systems.
Enterprise or organization administrators can set this concurrency limit under the Auto-scaling setting. GitHub-hosted runners with 4 or more vCPUs are available on both the GitHub Team and Enterprise plans.
If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.
We've added the ability to retrieve a repository's Contributing Guidelines via the GraphQL API. There is a new ContributingGuidelines object that's available under Repository object, when a CONTRIBUTING.md file is present.
This addition brings API parity with the other Community health files like CODE_OF_CONDUCT.md, which were previously available.
Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale.
Starting today, you can now create your own custom rules to control how Dependabot auto-dismisses and reopens alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.
For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, and – as rules apply to both future and current alerts – manage existing alerts in bulk.
At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.
That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.
Rules can be created across the following attributes:
| Attribute | Description |
|---|---|
severity |
Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical. |
scope |
Scope of the dependency: development (devDependency) or runtime (production). |
package-name |
Packages, listed by package name. |
cwe |
CWEs, listed by CWE ID. |
ecosystem |
Ecosystems, listed by ecosystem name. |
manifest |
Manifest files, listed by manifest path. |
Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.
Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.
Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories.
Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).
Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.
Let us know what you think by providing feedback — we’re listening!