Customers can now deterministically restrict their workflows to run on a specific set of runners using the names of their runner groups in the runs-on key of their workflow YAML. This prevents the unintended case where your job runs on a runner outside your intended group because the unintended runner shared the same labels as the runners in your intended runner group.
Example of the new syntax to ensure a runner is targeted from your intended runner group:
runs-on:
group: my-group
labels: [ self-hosted, label-1 ]In addition to the workflow file syntax changes, there are also new validation checks for runner groups at the organization level. Organizations will no longer be able to create runner groups using a name that already exists at the enterprise level. A warning banner will display for any existing duplicate runner groups at the organization level. There's no restriction on the creation of runner groups at the enterprise level.
This feature change applies to enterprise plan customers as only enterprise plan customers are able to create runner groups.
In July 2022 the public npm registry migrated away from the existing PGP signatures to a new ECDSA signatures for signature verification.
PGP based registry signatures will be deprecated on March 31st 2023. This means no new packages will be signed with PGP keys from this date onwards and the public key hosted on Keybase will expire.
Read more about registry signatures.
GitHub Actions workflows often specify the version of an action using the commit SHA. Since commit SHAs are immutable, this ensures that Actions always picks the same version. Commit SHAs, however, are not very human friendly, so best practice is to include the semver version in a comment next to the SHA. Dependabot will now update the semver version in comments when updating Actions workflows with a commit SHA version.
Dependabot is open source, and we're thankful to first-time contributor @jproberts for this great addition!