Gitea: use repo topic as a cache

[stevefan1999-personal]

What would you like Renovate to be able to do?

I want to use the autodiscovery feature but I don't want to pull the repo every single time, causing a huge spike in our potato server. I don't want to use a cache either because there can be multiple instances of Renovate running at the same time (for different Gitea servers too, including my company ones and my personal ones) and using a consolidated cache would cause some synchronization issue. We are using a K8S cronjob for this so we can't afford to update the repo every time we make a new one. Obviously, we wanted a more dynamic choice.

This would greatly reduce the need for manually configuring the repos, while still keeping a clear intention to the rest of my teammates.

If you have any ideas on how this should be implemented, please tell us here.

We can use the Gitea topic support to filter projects that are manually tagged to want to onboard, like if the repo is tagged with renovate-managed.

If the filtered repo with topic does not have the config.json/config.js, it is considered to be in onboard mode.

Say if I have a stevefan1999/foo repo tagged with renovate-managed, and Renovate only clones that, tried to scan but not see renovate.json/renovate.js, we send a Configure Renovate/onboarding PR for that.

Is this a feature you are interested in implementing yourself?

Maybe

[viceice]

so basically you like to use a tag to disable repos from being processed by renovate.

so this can maybe implemented like the experimental autodiscover server filter I've done recently.

[stevefan1999-personal]

@viceice Quite close -- except I want to manually cherrypick the repos I want to auto-discover on

[viceice]

🤔 @stevefan1999-personal Please try to describe in more detail how you think this should work.

Renovate currently does this:

1. autodiscover repos, if enabled
2. apply autodiscover filter
3. append statically configured repos (filter duplicates)
4. process each repo

[stevefan1999-personal]

@viceice Yes I know, except I don't want to auto discover too much repo -- right now we have over 100 repos and I don't expect to clone them one by one because it will thwart our Gitea instance.

I want to use the topic instead to act as a filter without having to set the config.js/config.json every time to update the autodiscovery filter, since this not only would mean I have to update the Helm chart a lot (we use https://github.com/drone/charts btw), but we can't add it to the autodiscovery filter on demand sometimes due to permission issue that not all of us have RBAC permission to update the Helm chart and thus the filter while the audit team members are away.

This RBAC permission problem is specifically for us, so just think of it as a little shortcut for probing the candidates of autodiscovery targets by leveraging the topic feature to eagerly filter the search space early on.

[viceice]

ok, so what you like is to add a new topic¹ filter here:

renovate/lib/modules/platform/gitea/index.ts

Lines 349 to 354 in 3c56aec

	...(process.env.RENOVATE_X_AUTODISCOVER_REPO_SORT && {
	sort: process.env.RENOVATE_X_AUTODISCOVER_REPO_SORT as RepoSortMethod,
	}),
	...(process.env.RENOVATE_X_AUTODISCOVER_REPO_ORDER && {
	order: process.env.RENOVATE_X_AUTODISCOVER_REPO_ORDER as SortMethod,
	}),

So a repo needs a specific topic to be returned if it's defined.

Footnotes

1. https://try.gitea.io/api/swagger#/repository/repoSearch ↩

[viceice]

checkout this pr for implementation details

• feat(platform/gitea): configurable autodiscover repo sorting #18636

[stevefan1999-personal]

@viceice Thanks! Actually I did look up there before and know what to do but I'm gotta rest for now