GitHub Actions updates appear to be ignoring cooldown setting

[woodruffw]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

github-actions

Package manager version

N/A

Language version

N/A

Manifest location and content before the Dependabot update

https://github.com/pypa/pip-audit/blob/d3dfe2115fbe641433d093189cf37fcedecfdf04/.github/workflows/release.yml

dependabot.yml content

version: 2

updates:
  - package-ecosystem: pip
    directory: /
    schedule:
      interval: daily
    cooldown:
      default-days: 7

  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: daily
    cooldown:
      default-days: 7

Updated dependency

See pypa/pip-audit#1023.

TL;DR: Dependabot has upgraded pypa/gh-action-pypi-publish from 1.13.0 to 1.14.0. The upgrade looks structurally correct, but is in violation of the configured cooldown of 7 days, since 1.14.0 was released only hours ago:

https://github.com/pypa/gh-action-pypi-publish/releases/tag/v1.14.0

What you expected to see, versus what you actually saw

I expected no PR updating this action, at least until the cooldown period ended (approximately 7 days from now).

Native package manager behavior

N/A

Images of the diff or a link to the PR, issue, or logs

See pypa/pip-audit#1023.

Smallest manifest that reproduces the issue

I suspect this will reproduce the issue:

version: 2
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: daily
    cooldown:
      default-days: 7

[woodruffw]

From a quick look, I suspect what's happening here is that Dependabot is using the commit age to evaluate the cooldown. That passes since the tag is atop pypa/gh-action-pypi-publish@cef2210, which is over 7 days ago.

However, this is probably misaligned with user expectations: as an end user, I expected the cooldown to be evaluated from the point at which the tag (or release) was created, not its underlying commit. Evaluating from the underlying commit has the potential to bypass the controls intended by a cooldown around ensuring that security scanners and other parties have an opportunity to review the release before auto-upgrades occur.

[thavaahariharangit]

There is a solution provided in this PR: #14621

Please verify and get back to me if you still have further clarification

[woodruffw]

I don't believe this is fixed? I believe the underlying behavior here is essentially the same as #13078, which remains open.