Remove tekton task replacement rules from Renovate config

[qixiang]

The replacement rules added in 4ff3c33 migrated users from redhat-appstudio-tekton-catalog to konflux-ci/tekton-catalog. The migration is now complete, so these rules are no longer needed.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[qixiang]

Hi @chmeliik , the migration from redhat-appstudio-tekton-catalog to konflux-ci/tekton-catalog should be complete by now. I think we can safely remove the replacement rules to simplify the Renovate config. WDYT?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 47.06%. Comparing base (842b1f7) to head (2a4e88d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #487   +/-   ##
=======================================
  Coverage   47.06%   47.06%           
=======================================
  Files          22       22           
  Lines        2129     2129           
=======================================
  Hits         1002     1002           
  Misses       1050     1050           
  Partials       77       77           

Flag	Coverage Δ
unit-tests	47.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[staticf0x]

There are still some repositories in the last 7 days where the old packages are mentioned in Splunk logs, but from what I can see it's mostly old PRs still being open on (likely) old branches. Removing this would stop these updates of course, but the question is, is it acceptable to stop proposing the migration?

[qixiang]

I think this migration effort has been ongoing for about six months now, and we've already provided users with a sufficiently long window to complete the migration.

However, there's one question I'm not clear on: it seems that some tasks are still being published to quay.io/redhat-appstudio-tekton-catalog. As a result, some users can continue to receive task updates from the old repository, which may prevent them from realizing that they need to perform the migration. In practice, the migration itself is quite straightforward, users only need to merge the PR opened by MintMaker.

@mmorhun @chmeliik any insights?

[chmeliik]

I was going to check Splunk logs but then got distracted, thanks @staticf0x for doing that 👍

The situation is roughly this:

We do still update the tasks in quay.io/redhat-appstudio-tekton-catalog, because we don't have a good mechanism to deprecate a task in redhat-appstudio-tekton-catalog without also deprecating it in konflux-ci/tekton-catalog at the same time. We could stop updating them, but then users could just keep using the outdated tasks forever.

The trusted_task_rules model should help here, looks like it will be available soon: release-engineering/rhtap-ec-policy#209. Once this is available, I believe it will be easy to globally disallow the usage of redhat-appstudio-tekton-catalog refs by a certain date.

I would say that MintMaker definitely doesn't need to open new PRs for the migration, everyone who had the old references should have received one by now. But ideally, it should still keep updating the ones that are already open and haven't been merged, which still requires this config I assume.

[qixiang]

I would say that MintMaker definitely doesn't need to open new PRs for the migration, everyone who had the old references should have received one by now. But ideally, it should still keep updating the ones that are already open and haven't been merged, which still requires this config I assume.

I think we can keep this for a while after release-engineering/rhtap-ec-policy#209 is deployed. In theory, once that feature is deployed, users will have to use tasks from quay.io/konflux-ci/tekton-catalog/. After that, there should be no need to keep this anymore. @chmeliik is this correct?

[chmeliik]

I would say that MintMaker definitely doesn't need to open new PRs for the migration, everyone who had the old references should have received one by now. But ideally, it should still keep updating the ones that are already open and haven't been merged, which still requires this config I assume.

I think we can keep this for a while after release-engineering/rhtap-ec-policy#209 is deployed. In theory, once that feature is deployed, users will have to use tasks from quay.io/konflux-ci/tekton-catalog/. After that, there should be no need to keep this anymore. @chmeliik is this correct?

That PR alone won't disallow redhat-appstudio-tekton-catalog. A deny rule would have to be added to disallow them explicitly, otherwise they will still be allowed by the existing data-acceptable-bundles data

[qixiang]

@chmeliik thank you for your input. I'll keep this open until there is a policy that disallows Tekton tasks from redhat-appstudio-tekton-catalog, or continue supporting it for a few more months.

[chmeliik]

Filed an internal tracker to add the policy rule (https://redhat.atlassian.net/browse/STONEBLD-4582)