with: telemetry: false

[TheJaredWilcurt]

    steps:
    - uses: actions/checkout@v4
    - uses: moonrepo/setup-toolchain@v0
      with:
        auto-install: true
        telemetry: false

Warning: Unexpected input(s) 'telemetry', valid inputs are ['auto-install', 'auto-setup', 'cache', 'cache-base', 'cache-version', 'moon-version', 'proto-version', 'workspace-root']

Until Proto's telemetry is changed to Opt-in, I cannot use this library for GitHub Actions. There is no reason the tool that sets my Node version should be collecting data about me, my machine, or my CI.

[polarathene]

Until Proto's telemetry is changed to Opt-in, I cannot use this library for GitHub Actions.

Use a value with the PROTO_TELEMETRY ENV that does not get parsed into true:

steps:
  - uses: actions/checkout@v4
  - uses: moonrepo/setup-toolchain@v0
    env:
      PROTO_TELEMETRY: disable
    with:
      auto-install: true
      telemetry: false

See moonrepo/proto#915 (comment) for more details

---

There is no reason the tool that sets my Node version should be collecting data about me, my machine, or my CI.

There's nothing particularly concerning in the collected telemetry. Plenty of software out there will collect this without as much transparency about doing so and fingerprint you.

The only identifier in this case is the Proto UUID, which you can consider similar to IP address that various web services receive as PII (Personally Identifiable Information) and can then anonymize that personal data (as per GDPR) when processing.

Legal requirements vary depending on context of the data, but there are relaxed cases (assuming data is processed/anonymized properly), where it's deemed necessary for a service to function (including logs for diagnostics for example).

Thankfully, Proto is rather clear about telemetry usage and supports opt-out. Though I agree this action could better communicate that by documenting the ENV (not sure it really warrants a dedicated input?).

[TheJaredWilcurt]

Which of these is correct, and whatever the answer is, it should be documented clearly for everyone:

# A. root level
env:
  PROTO_TELEMETRY: disable

# B. root level
env:
  PROTO_TELEMETRY: false

    # C. Nested
    - uses: moonrepo/setup-toolchain@v0
      env:
        PROTO_TELEMETRY: disable
      with:
        auto-install: true

    # D. Nested
    - uses: moonrepo/setup-toolchain@v0
      env:
        PROTO_TELEMETRY: false
      with:
        auto-install: true

[polarathene]

They're all correct. I'd personally go with C as intent is communicated more clearly.

---

• Your root vs step ENV location is irrelevant. That's GHA specific:
  • You decide if the ENV should be set globally for all steps executed, or only when running a specific step(s).
  • Global ENV is convenient when implicitly used by many steps, or for expressing variables where there's more visibility.
  • Step ENV is better co-located for awarenesss to the reader, and makes more sense when the value is static and doesn't need to be shared or repeated across other steps/jobs or assigned via ${{ env.ENV_KEY }} expression as a value to keys in with or used in conditionals, etc.
• Both values for PROTO_TELEMETRY would be valid for opt-out, which one is more clearer to you for context of what effect that'd have on an ENV like PROTO_TELEMETRY is up to your preference. disable is probably more clearer, but it could just as easily be PROTO_TELEMETRY: no-thank-you too 🤷‍♂️

I already provided you with information on how to opt-out of telemetry:

What the docs fail to communicate, and is less obvious from that source is that the telemetry setting is configurable via ENV (PROTO_TELEMETRY), not just config file.

The env::parse_bool method used on the ENV / config value accepts a variety of values to parse as true, and anything else as false. So you can use PROTO_TELEMETRY=0 / PROTO_TELEMETRY=false / PROTO_TELEMETRY=no, etc.

Regarding your question between using disable vs false, both will opt-out (as my quote above from my advice explained).

For added clarity, the env::parse_bool method is documented as:

Parse a string into a boolean. Will parse 1, true, yes, on, and enabled as true, and everything else as false.

So you can use any value as long as it's not one of the truthy values (1/true/yes/on/enabled).