validating nested configs in private repository

[travi]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitHub Enterprise Cloud, Renovate 37.413.2

Please tell us more about your question or problem

I'm building some shareable configs for reuse across teams and am wanting to use the config validator to make sure we avoid simple issues. I've used the validator successfully in public repos, but am running into problems when attempting to use in private repos.

All is fine until attempting to validate a config that extends another config, even if that extended config is in the same repo. In this situation, the validator returns the error shown in the logs section below. Especially since I don't have this problem with my public configs (even when they extend others), I imagine the problem is that the validator is unable to fetch the extended config from the private repository. So, I'm curious if there is a way to provide a token to enable it to fetch, or if there are other steps to accomplish this goal.

Logs (if relevant)

Logs

INFO: Throwing preset error
       "validationError": "Cannot find preset's package (github>path/to/existing/config)"

[rarkins]

I guess it's because the validator doesn't have access to hostRules from your global config?

One idea I've had is to add the concept of --dry-run=config where Renovate runs just enough to validate the config. You could of course run it today with --dry-run=extract and get nearly the same thing (just a little more work) so maybe it's not that helpful.

The remaining problem is that this will require the config to be on the default branch, meaning you have to commit it to test it that way, which is not so good.

Maybe instead we could have a different approach like --validate-config-branch=foo which will treat foo as the default branch to load config from.

This assumes that you are OK with validating against a branch in a repo instead of locally. Do you have a hard requirement that you need to test against a local file?

[rarkins]

Yes, validator has no awareness of platform, token, etc.

[travi]

does the github> directive in the extends property clarify the platform to the validator?

[rarkins]

Yes, in that case Renovate/validator would know it means github.com

[travi]

it looks like GlobalConfig.set doesnt accept setting a token value. Is there another way to provide the token currently that I'm still overlooking?

[rarkins]

There is no way that I'm aware of

[travi]

One idea I've had is to add the concept of --dry-run=config where Renovate runs just enough to validate the config.

Circling back to this, I'm wondering which paths might be available to consider moving forward with, if any. Since it seems like the limitation for my goal is the ability to set a token, it seems like the shortest path might be to expose a way to provide that as an environment variable to cli argument for the validator. You all could say that is a path that has other concerns beyond what I understand and that the partial Renovate run is the better path.

To share one other scenario that is on my mind in case it sparks additional thoughts for this case: we are looking to identify which shared configs are used by various internal repositories so that we can compare to other metrics to get a better sense for whether the configs are encouraging successful behaviors. The ability to extend configuration in a nested fashion makes tracing usage starting from the .whitesource file challenging enough that we've wondered if there might be a way to leverage the implementation from Renovate directly rather than building our own. I don't find an exposed way to reuse this capability, and I expect it would be fairly unlikely that you would see enough value in exposing it, but I expect that implementation would hit the same auth limitation if it were exposed. Again, I don't share this thought with the expectation that this is likely to be exposed, but more in case it sparks other thoughts on how the fetching of extended configs might be approached beyond what might have already been considered.

Do you think there is a path toward enabling validation in a way that enables internal/private repo access?

[rarkins]

Please clarify if I understand this correctly?

• For now you are focusing on validating local changes
• You run with platform=local
• It fails because of github> preset lookups?

Something to keep in mind is that many users use SSH auth to clone repos from GitHub and Renovate couldn't use an SSH to lookup presets using the GitHub API. You'd need to have a PAT available - is that feasible for you?

BTW my recommendation is to avoid .whitesource config as much as possible and instead use Renovate's native configuration files/approaches.

[travi]

Please clarify if I understand this correctly?

• For now you are focusing on validating local changes
• You run with platform=local
• It fails because of github> preset lookups?

I'm not completely clear on which context you are referring to "local" in, so i'll try to answer for the two in my mind

• ideally, we would like to run the validator both locally on a developer's machine and in a CI pipeline
• i was using github> and RENOVATE_PLATFORM=github rather than local> and RENOVATE_PLATFORM=local but have now tried both and the failure is the same

Something to keep in mind is that many users use SSH auth to clone repos from GitHub and Renovate couldn't use an SSH to lookup presets using the GitHub API. You'd need to have a PAT available - is that feasible for you?

using a PAT would be an understandable requirement and easy to fulfill within a CI pipeline. a developer would need to take a step to have one available locally, but that would be acceptable

BTW my recommendation is to avoid .whitesource config as much as possible and instead use Renovate's native configuration files/approaches.

my guidance to teams has been to only enable renovate within the .whitesource and extend a separate config file for renovate details. for the context of these shareable configs that I'm attempting to use the validator against, there is no .whitesource file involved and the target files are expected to be completely valid renovate config