[BUG] Flags resembling floating point numbers get corrupted on upload

[webknjaz]

Describe the bug

So I'm using codecov/codecov-action and I was setting up its flags input. I've got a matrix of Python interpreter versions that look like "3.8", "3.9", "3.10" and I was turning those entries into flags via ${{ matrix.python-version }}.
At some point, when I got it working, I noticed an unexpected flag showing up on the Codecov website — 3.1. Check out upload number 2975475115 at https://app.codecov.io/gh/sphinx-contrib/sphinxcontrib-towncrier/commit/a6873b20e6f55b99eba920e7351c99866a88fdb2 to see it. I immediately guessed that it was coming from jobs running Python 3.10 because I've seen similar bugs. For example, a YAML parser would parse a 3.10 literal as 3.1 if it's not quoted or otherwise represented properly. But this was not the case.

It is clearly visible in the CI log that the flags passed to the action are flags: GHA,Linux,3.10,towncrier-v21.3.0 — https://github.com/sphinx-contrib/sphinxcontrib-towncrier/runs/8146489603?check_suite_focus=true#step:10:4.

Later in the log, the recorded invoked CLI command is visible as /home/runner/work/_actions/codecov/codecov-action/v3/dist/codecov -n -Q github-action-3.1.0 -f .test-results/pytest/cov.xml -F GHA -F Linux -F 3.10 -F towncrier-v21.3.0 — https://github.com/sphinx-contrib/sphinxcontrib-towncrier/runs/8146489603?check_suite_focus=true#step:10:21. So this indicates that the value passed to this uploader is correct — it's "3.10".

Further down, I saw the logged HTTP request URL that reveals that the problem isn't happening on the server side of Codecov but somewhere in the uploader:

[2022-09-01T23:00:59.390Z] ['info'] Pinging Codecov: https://codecov.io/upload/v4?package=github-action-3.1.0-uploader-0.3.0&token=*******&branch=master&build=2975475115&build_url=https%3A%2F%2Fgithub.com%2Fsphinx-contrib%2Fsphinxcontrib-towncrier%2Factions%2Fruns%2F2975475115&commit=a6873b20e6f55b99eba920e7351c99866a88fdb2&job=%F0%9F%91%B7tests&pr=&service=github-actions&slug=sphinx-contrib%2Fsphinxcontrib-towncrier&name=&tag=&flags=GHA%2CLinux%2C3.1%2Ctowncrier-v21.3.0&parent=

(https://github.com/sphinx-contrib/sphinxcontrib-towncrier/runs/8146489603?check_suite_focus=true#step:10:38)
If you look closer into the flags query argument, you'll see this bit: %2C3.1%2C — it's ,3.1, when url-decoded.

Digging deeper, I double-checked that there are no conversions on the action side. Then, I looked into the uploader's codebase and haven't found any code turning individual flags into numbers.

This is when I realized that the inputs coming into the uploader code must already be pre-transformed. I identified yargs as a library implementing CLI argument parsing, found that --flags/-F is declared at https://github.com/codecov/uploader/blob/dae22df7/src/helpers/cli.ts#L54-L59 / https://github.com/codecov/uploader/blob/dae22df7/src/helpers/cli.ts#L213. Then checked out the docs at https://yargs.js.org/docs/#api-reference-optionskey-opt, noticed that the example has type: 'string' in the declaration and the uploader doesn't. Also, the docs don't say anything about defaults of this type setting. And the source code wasn't clear about that either. I've quickly put together a yargs-only reproducer to confirm my suspicion — it's an untested corner case in this library that causes the above side effect. I've already filed an issue about this on their tracker.

FWIW, the workaround for this bug on the uploader's side seems pretty straightforward — just declare the string type for this option.

To Reproduce

Calling codecov -F 234.12300 ... should be enough to trigger this.

Expected behavior

The flag showing up in Codecov should be the same as specified in the uploader invocation.

Screenshots

https://github.com/sphinx-contrib/sphinxcontrib-towncrier/runs/8146489603

Additional context

yargs/yargs#2232