Skip to content

Merges by pull request merge queue now attributed to the GitHub Merge Queue bot

We've shipped a fix to ensure merges by the pull request merge queue are always attributed to the GitHub Merge Queue bot (github-merge-queue[bot]). This change applies to new merges by the queue, and will appear in the activity view and in push webhook events.

We want to hear from you! Let us know if you have questions or feedback.

Today, we are announcing that larger hosted runners for GitHub Actions are generally available for paid Team and Enterprise Cloud plans! This feature has been in public beta since September of 2022 where customers have been using it in production to run their CI/CD jobs faster and with more flexibility.

larger runner machine sizes

The new larger runners provide new capabilities:

  • Larger Linux and Windows machines: This allows development teams to use machine sizes up to 64 vCPUs with 256 GB of RAM, and 2 TB of SSD storage to support their on-demand CI/CD jobs and other workflows. Larger runners are charged by the job minute for both private and public repositories and do not consume included minutes.
  • Static IP address to enable secure access to your resources: Enterprise Cloud customers can now choose whether a static IP address range will be assigned to their larger runner instances. This provides a fixed IP address range that you can add to your allow list for access to internal systems. You can also use this in conjunction with GitHub’s IP allow list to enable hosted actions runners and IP allow listing at the same time.
  • Administrative control over access to larger runners and concurrency: Your administrators can decide who has access to larger machine sizes and at what concurrency, providing guard rails on spending.

You can learn about the larger runner per job minute pricing by checking the current pricing documentation and learn more about this feature by digging into the documentation.

If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.

See more

Suppressed notifications for Dependabot alerts at enablement time

At first time enablement, Dependabot will no longer send web or email notifications that summarize when a repository is populated with Dependabot alerts. Now, you'll have visibility across all your Dependabot alerts without immediately notifying developers who watch security alerts across your repository or organization. This change applies across all levels: repository, organization, and enterprise.

For any developers both watching a repository and opted in to receive Dependabot alert notifications, future notifications will still be sent for incoming alerts after enablement, as well as for daily and weekly digests.

About this change

We’ve been working to steadily improve our security alert notifications. As part of our notification strategy, notifications will no longer be sent at first time enablement for Dependabot alerts. Notifications are muted across all levels of enablement: repository, organization, and enterprise.

This change does not affect email digests or notifications on newly created alerts after enablement.

Available alert notifications and indicators

Today, when a dependency-based vulnerability is detected, Dependabot lets you know based on your user notifications settings and repository watching settings. You can opt to receive:

  • Web-based notifications on alerts in your GitHub inbox
  • Email-based notifications on alerts
  • Email digests (weekly or daily roll-ups of alerts).

From the UI, you can also use the "Security" alert count in your repository navigation as an indicator for when your repository has alerts. This Security tab includes the count for all active Dependabot alerts, code scanning alerts, secret scanning alerts, and any security advisories that you have permissions to view.

Learn more about Dependabot alerts and configuring notifications for alerts.

See more