[v4] git as implied requirement

[DArtagan]

Hi, I've been tracking the progress of v4 - to move our company over when possible.

We run our tests and codecov in a container. With this most recent version (4.1.0), an error is thrown:

Error: Unable to locate executable file: git. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

Which makes sense - we don't have git installed inside that container. Is it intentionally a requirement for uploading with codecov?

In looking for a work-around I also noticed one possible typo I wanted to raise, diable. For example:

const disableSafeDirectory = isTrue(core.getInput('diable_safe_directory'));

Thanks - let me know if there's any additional information I can provide.

[DArtagan]

Typo fixed in #1343! Whether git is an intentional requirement for uploading remains an open question.

[thomasrockhu-codecov]

@rohan-at-sentry to investigate and prioritize, the CLI I think is not git agnostic.

[rohan-at-sentry]

@DArtagan , yes git is indeed a requirement for the CLI today.

Were you able to find a workaround for your usecase?

[DArtagan]

I couldn't find documentation about it, so we've just not upgraded to v4.

[rohan-at-sentry]

@DArtagan this is now documented better on our docs here.

I'm wondering if you were able to try running the CLI in docker as outlined here?

[DArtagan]

I do appreciate the updated docs. Honestly, when setting it up the Action - we just used what was written in the README of this repo. (I don't think that README yet mentions that this Action is dependent on a Git binary.)

If I'm following, the "Running test within containers" link you included seems to be a short two sentences linking to "Here's how you can set up Codecov CLI to upload to Codecov". That page suggests CURLing a script from a URL and bash-executing it to set environment variables? Emotional reaction: that gives me the heebie-jeebies for a production pipeline - one has no control over what's on the other side of the URL, it feels unsafe. No hashing or anything to guarantee consistent deterministic behaviour. But it also wouldn't install Git into the container either.

Happily our Workflow is pretty much right out of the README example. Though we first ask the GitHub runner to spin up the container, and then run all following commands inside it:

jobs:
  python-tests:
    container:
      image: ${{ inputs.image }}  # our container image name
    steps:
      - name: Run Python tests
        run: python -m pytest --cov=app --cov-report xml:coverage/coverage.xml --cov-report term:skip-covered
      - uses: codecov/codecov-action@ab904c41d6ece82784817410c45d8b8c02684457
        with:
          token: ${{ secrets.codecov_token }}
          files: /coverage/.coverage,/coverage/coverage.xml,/coverage/lcov.info
          flags: unittests
          fail_ci_if_error: true
          root_dir: /app

[webknjaz]

FTR v5 has the same problem. I was just updating v3 to v5 in python/trio and hit this in the job running an Alpine container.

[webknjaz]

Actually, v5 has even more implicit deps: curl, gpg, git, jq.