Skip to content

Dependabot pull requests pause for inactivity

What’s new?

Starting today, Dependabot will pause automated pull request activity if you haven’t merged, closed, or otherwise interacted with Dependabot for over 90 days. To resume activity when you’re ready, simply interact with Dependabot.

This change will help Dependabot be more focused to the repositories you care about.

When will Dependabot become paused?

This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.

The following must be true for at least 90 days:

  • Has not had a Dependabot PR merged
  • Has not had changes made to the Dependabot config file
  • Has not had any @dependabot comment-ops performed
  • Has not had any Dependabot PRs closed by the user
  • Has received at least one Dependabot PR before the 90 day window
  • Has at least one Dependabot PR open at the end of the 90 day window
  • Has had Dependabot enabled for this entire period

How will Dependabot let me know?

Dependabot will add a banner notice to open Dependabot pull requests, the repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).

Who can use this feature?

This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven’t interacted with these pull requests for a while, will be affected.

This change will start to roll out today, expanding through January 2023 to include all repositories owned by individuals and by organizations with free and Team plans.

Later, it will roll out to GitHub Enterprise Cloud and GitHub Enterprise Server customers, where this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners.

Learn more about this change.

Second-factor validation after 2FA setup

GitHub.com users who set up two-factor authentication will see a prompt after 28 days, asking them to perform 2FA and confirm their second factor settings. This prompt helps avoid account lockout due to misconfigured authenticator applications (TOTP apps), especially those that failed to save the TOTP secret after validating it during set up.

This prompt appears in existing sessions if you haven't already performed 2FA as part of a sudo prompt or signing in on another device. If you find that you can't perform 2FA, you'll be presented with a shortcut that allows you to reset your 2FA setup.

image

All users that enable 2FA will be eligible for this prompt, including users required to enable it by their organization or GitHub itself.

To learn more about two-factor authentication, see "Configuring two-factor authentication".

See more

GitHub Actions: OpenID Connect token now supports more claims for configuring granular cloud access

OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.
Each OIDC token includes standard claims like the audience, issuer, subject and many more custom claims that uniquely define the workflow job that generated the token. These claims can be used to define fine grained trust policies to control the access to specific cloud roles and resources.

  • We now support more custom claims within the token : actor_id, repository_id, repository_owner_id
    workflow_ref, workflow_sha and job_workflow_sha – to help uniquely verify the source of a workflow job, even if the job references a reusable workflow.
  • We are also adding these new attributes as default environment variables and also to github context

These changes enable developers to define more advanced access policies using OpenID connect and do more secure cloud deployments at scale with GitHub Actions.

Learn more about Security hardening your GitHub Workflows using OpenID Connect.

See more
View all changes