Are non-FQDN host rule environment variables supported at all?

[emwl]

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.

GitLab-CE with Renovate 39.31.4

Please tell us more about your question or problem

I recently had to regenerate access tokens for our on-premise Azure DevOps Server NuGet feed, and because it was a good reason to try it, I wanted to remove it from the host rules in favor of a GitLab CI variable (that ends up as environment variable). I thought I tried the same thing before and failed, which is why I had the token hardcoded/plaintext (which is never a good idea, but I just wanted to get things to work back in the day).

The (relevant part of the) config looks like this:

 {
   "$schema": "https://docs.renovatebot.com/renovate-schema.json",
   "packageRules": [...],
   "nuget": {
     "registryUrls": [
       "https://api.nuget.org/v3/index.json",
       "https://tfs/MainCollection/_packaging/NUGET_PACKAGES/nuget/v3/index.json"
     ]
   },
   "hostRules": [
     {
       "hostType": "nuget",
       "matchHost": "https://tfs/MainCollection/",
-      "password": "old token"
     }
   ],
   "configMigration": true,
   "platformAutomerge": true,
   "extends": [...]
 }

After removing the password member, I added a CI variable named NUGET_TFS_PASSWORD instead with the new token and used the various masking/protection features of GitLab to prevent them from showing up in a log accidentally.

However, the following run failed to access the NuGet feed with this:

 WARN: Cannot parse env
       "env": "NUGET_TFS_PASSWORD"

I did find #10211 and apparently, single-word hostnames always trigger this warning (then skip the rule). We don't use the FQDN to access the NuGet feed, and changing this configuration across many projects (and even more developer machines) isn't really something we want to do if we can avoid it. "tfs" is just a DNS alias, in case we ever migrate to a different server.

The way I understand

renovate/lib/config/env.ts

Line 114 in 854d0a8

logger.warn(`Cannot parse ${envName} env`);

...it seems that those hostnames are not supported at all. Is there anything I can do about it, other than changing the hostname everywhere else to a FQDN?
Putting it back into the json config does the trick, but isn't really optimal.

Logs (if relevant)

Logs

$ npx renovate $RENOVATE_EXTRA_FLAGS
DEBUG: Using RE2 regex engine
DEBUG: Parsing configs
DEBUG: Checking for config file in config.js
DEBUG: Converting GITHUB_COM_TOKEN into a global host rule
DEBUG: File config
       "config": {
         "endpoint": "https://gitlab/api/v4/",
         "platform": "gitlab",
         "onboardingConfig": {"extends": ["renovate/config"]},
         "autodiscover": true,
         "autodiscoverFilter": ["!/infra/.*/"],
         "optimizeForDisabled": true,
         "persistRepoData": true,
         "detectGlobalManagerConfig": true,
         "detectHostRulesFromEnv": true
       }
DEBUG: CLI config
       "config": {}
DEBUG: Env config
       "config": {
         "hostRules": [
           {"hostType": "github", "matchHost": "github.com", "token": "***********"}
         ],
         "dryRun": "full",
         "baseDir": "E:\\GitLab\\builds\\gqSWmGzn\\1\\renovate\\runner/renovate",
         "endpoint": "https://gitlab/api/v4",
         "token": "***********"
       }
DEBUG: Combined config
       "config": {
         "endpoint": "https://gitlab/api/v4",
         "platform": "gitlab",
         "onboardingConfig": {"extends": ["renovate/config"]},
         "autodiscover": true,
         "autodiscoverFilter": ["!/infra/.*/"],
         "optimizeForDisabled": true,
         "persistRepoData": true,
         "detectGlobalManagerConfig": true,
         "detectHostRulesFromEnv": true,
         "hostRules": [
           {"hostType": "github", "matchHost": "github.com", "token": "***********"}
         ],
         "dryRun": "full",
         "baseDir": "E:\\GitLab\\builds\\gqSWmGzn\\1\\renovate\\runner/renovate",
         "token": "***********"
       }
DEBUG: Detecting global manager config
DEBUG: Detected C:/Users/tfssrv/.npmrc and adding it to global config
DEBUG: Global manager config
       "config": {"npmrc": "***********", "npmrcMerge": true}
 WARN: Cannot parse env
       "env": "NUGET_TFS_PASSWORD"
DEBUG: Adding trailing slash to endpoint

[rarkins]

It's possible that the if statement we have should be more generous:

        } else if (splitEnv.length === 1) {
          logger.warn({ env: envName }, 'Cannot parse env');
          continue;
        } 

Do you have the ability to run from source to test that it "just works" otherwise if you make a simple change to allow it?

[emwl]

Not at the moment, no. I can potentially try this early next year, since the rest of this week is pretty much full of other stuff, then I'm leaving on vacation.

Although, did you mean to leave the continue in there? As far as I understood that, it skips further processing because of the continue.
What we'd need there would be something like

        } else if (splitEnv.length === 1) {
          logger.warn({ env: envName }, 'Found non-FQDN env that might not be intended as host rule');
          matchHost = splitEnv[0];
        } 

Or just remove the check to let the else do the work. I haven't checked the history why this test/warning even exists in first place, and whether it still makes sense today.

[rarkins]

I think the continue was intentional as it was assumed that a one-word hostname was invalid. I think we could make the modification you suggest.

[emwl]

Sorry for the late reply, life got in the way. But yeah, I had the chance to look at the changes in the mean time, and it looks like it was simply introduced with the feature back in the day (but I couldn't find any rationale on the why).
I'd appreciate that change, and I'm probably not the only one (I know of a few acquaintences that also use non-FQDN hosts in their network for convinience reasons).

And if not, I have a workaround (even though it isn't the best approach to put that password in a version-controlled file).

[rarkins]

Converted to issue: #33607