Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuring a repository to be exempt from renovate management #1654

Open
grayside opened this issue Jun 7, 2023 · 3 comments
Open
Labels

Comments

@grayside
Copy link
Contributor

grayside commented Jun 7, 2023

Problem

For JSS repositories, we are likely to require customized renovate configurations. There are some aspects of the CFT-managed renovate configuration we may want to retain.

Proposal

  • Allow configuring opt-out of a repository from renovate management by CFT
  • Consider moving some of the template renovate configuration to GitHub-hosted presets so repositories that opt out can easily include custom regexManagers or other configurations that may remain universally useful.
@bharathkkb
Copy link
Member

I think the first option with opt-out should be straightforward to implement. I will defer to @apeabody who has most context for any suggestions/recommendations.

@apeabody
Copy link
Collaborator

apeabody commented Aug 2, 2023

@bharathkkb

To implement the opt-out I would suggest adding a new bool to the repos map. While the renovate.json uses the generic repo_file module, you could then use an in-line expansion to filter here.

I also like the idea of moving some/most of our renovate config to a central present to reduce the need to push some changes (e.g. regexManagers) to the actual repo config files.

@grayside

Do you have more detail on the desired customization? We can certainly publish a preset for inclusion, just curious (beyond the obvious custom regexManagers) what might be/not be universally useful. Cheers!

@grayside
Copy link
Contributor Author

regexManagers are the main thing, possibly with more flexibility in supporting *.cloudbuild.yaml instead of the limitation on int or lint currently in place.

It may be useful to have terraform grouping rules in place as well (perhaps as a separate preset).

I'm not sure how to interpret some of the constraints around Go updates & version constraints, if those are in place to ensure CFT library compatibility, that may also be a valuable preset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants