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

Enforce manager -> datasource links for better documentation #5651

Closed
rarkins opened this issue Mar 5, 2020 · 0 comments · Fixed by #13621
Closed

Enforce manager -> datasource links for better documentation #5651

rarkins opened this issue Mar 5, 2020 · 0 comments · Fixed by #13621
Assignees
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:requirements Full requirements are not yet known, so implementation should not be started type:refactor Refactoring or improving of existing code

Comments

@rarkins
Copy link
Collaborator

rarkins commented Mar 5, 2020

I think users would benefit if each manager's documentation page stated which datasource values it supported, e.g. docker, github-tags, etc. Ideally this would be auto-generated from the code like we do for fileMatch (see https://docs.renovatebot.com/modules/manager/cocoapods/ for an example).

I can think of a few ways to do this, although each has a downside:

  1. Scan each manager's files for references to datasource/* imports and then use that to build the list. If any manager uses literal strings though, it won't catch them. Also it's a little challenging because we don't mandate file names within a manager.

  2. Mandate that each manager export a list of datasources it supports, and then have datasource/index enforce that no returned deps have a datasource that mismatches. The problem here is (a) extra work (not too much..) and (b) we'd need to make sure that managers don't test themselves directly and instead test via the index function.

I guess I'd lean towards the first approach, because it should be correctly nearly all of the time but also there's not really a huge problem if documentation is temporarily wrong until someone spots it.

@rarkins rarkins added needs-requirements priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:refactor Refactoring or improving of existing code labels Mar 5, 2020
@rarkins rarkins added the status:requirements Full requirements are not yet known, so implementation should not be started label Jan 12, 2021
@viceice viceice closed this as completed Dec 30, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:requirements Full requirements are not yet known, so implementation should not be started type:refactor Refactoring or improving of existing code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants