Allow override `internalChecksFilter=strict` when PR exists

[viceice]

What would you like Renovate to be able to do?

Sometimes i like to force a minor or major update, even it's filtered by internalChecksFilter. Ideally i have a new section on dashboard to force the update.

Did you already have any implementation ideas?

Some minimal. I think it's a good idea to add a new internal update status field, which corresponds to the dashboard state. So if you check the force checkbox, wenovate knows what to do next and don't use the force for all.

EG:

• status: wait for schedule and check force
• create branch and status=pending (no pr yet), stop
• next run: check status and do automerge / open pr as required if status checks match.

[rarkins]

Is the branch pending or it exists with a lower (passing) version?

[viceice]

branch exists with lower pending patch https://github.com/viceice/dotnet-ts-testing/pull/156

[rarkins]

I was thinking it would be better to add a checkbox to the PR itself noting that a newer version is a available and to tick it to force the new version. Ie not dashboard

[viceice]

Sounds good too

[HonkingGoose]

I was thinking it would be better to add a checkbox to the PR itself noting that a newer version is a available and to tick it to force the new version. Ie not dashboard

How about having the checkbox on the PR and on the dashboard?

---

On the PR (build(deps): update dependency eslint to v7.29.0), add a checkbox like:

• [ ] If you want to update eslint to v7.30.0, check this box.

---

On the dashboard, have a new section that collects all "outdated branches" and lists them with a checkbox:

Outdated branches

These updates are outdated compared to the latest published package. Click the checkbox to update the package to the latest version:

• [ ] build(deps): update dependency eslint to v7.29.0 -> v7.30.0

[rarkins]

I've been wondering if we should redesign the dashboard so that it separates out display from controls. Controls can be within a collapsed details section. Then for platforms without checkboxes we could still have the visual display part. Also, checkboxes limit out display options currently (eg can't be within a table)

[rarkins]

I started implementing a PR to close this issue but instead pivoted to something smaller: #13768

Regarding the PR checkbox approach, these parts are resolved/implemented:

• We can't embed checkboxes with tables, which means we can't do pending updates per-repo when there's a group. I think this is an OK limitation
• We therefore need to have a single checkbox per-PR like the rebase/retry one which applies to any and all pending updates within the PR
• If that checkbox is ticked, we need to keep it ticked until the user unticks it - so this is unlike rebase/retry

Here's the hard bit:

• internalChecksFilter is applied during the lookup phase, prior to any branch being decided
• We can only fetch the PR once we know the branch later on
• If we fetch the PR, and find pending checks should be used, we need to change not only newVersion but also newValue, displayTo, etc. It also might need release notes fetching changed. We might want to refactor to defer these generated fields to accommodate