Support for go modules in subdirectories

[ryeguard]

I have a project where the root does not contain the go module (go.mod, etc). It would be nice to be able to support creating a badge for such projects.

I looked around in the code but I could not find support for it in the current state. Please correct me if I am wrong. Would you be open to supporting this? If so, I can help out implementing it.

Ideally, it would be nice if the workflow "respected" the working-directory which can be set on jobs/steps. (It does not seem to be that way currently.)

I.e., it'd be nice if the following worked as expected. It does not now.

on:
  push:
    branches: ["main"]

jobs:
  test-and-coverage:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./dir/to/module

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v4
        with:
          go-version: "1.22"

      - run: go test -v ./...

      - name: Go coverage report
        uses: ncruces/[email protected]

[ncruces]

This project has increasingly steered away from generating coverage for anything but a bog standard simple repo, where the default just works.

We focus on the badge, the chart, the report, and saving those in the wiki in a seamless way.

What you can do, what I do for any more complex case, is to generate the coverage file yourself, and then use this action to generate the report/badge/chart from that file using the coverage-file input property.

So, instead of:

run: go test -v ./...

Do whatever you need to test your package with coverage, and write coverage to a file like coverage.out.

Then do:

- name: Update coverage report
  uses: ncruces/go-coverage-report@v0
  with:
    coverage-file: coverage.out

[ncruces]

I missed the working-directory bit. I can look into that, if I can be persuaded that it makes sense.

But really, I want to keep this simple and straightforward. Otherwise, the escape hatch is that you can generate coverage however you want, and this simply does the rest.

E.g. here I use an entirely different tool to generate coverage.

[ncruces]

Ideally there wouldn't be any new configuration parameters.

If I'm not respecting existing GitHub Actions configuration parameters (e.g. that the Go action supports), then that's something I'd really like to fix.

[ncruces]

working-directory does not support uses steps, so this would need to be a new configuration knob, which I'd rather avoid.

You can generate your own coverage in a run step, and then pass the output to the action.