Respect the default working-directory of a job

[loshz]

When setting the default working-directory of a job, golangci-lint-action does not respect this parameter.

For example, I have the following project structure:

├── .github
│   └── workflows
│       └── ci.yml
├── some_dir
│   ├── .golangci.yml
│   ├── go.mod
│   ├── main.go
│   └── README.md
└── README.md

And a configured GitHub actions job:

jobs:
  lint:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: some_dir
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-go@v2
        with:
          go-version: 1.17
      - uses: golangci/golangci-lint-action@v2
        with:
          version: v1.43

To which I receive the following error:

Running [/home/runner/golangci-lint-1.43.0-linux-amd64/golangci-lint run --out-format=github-actions] in [] ...
level=error msg="Running error: context loading failed: no go files to analyze"

This is because golangci-lint run is still being ran from the root directory. If I pass the working-directory arg to the GH action, it works as expected:

- uses: golangci/golangci-lint-action@v2
  with:
    version: v1.43
    working-directory: some_dir

As I can see the --path-prefix flag being passed:

 Running [/home/runner/golangci-lint-1.43.0-linux-amd64/golangci-lint run --out-format=github-actions --path-prefix=some_dir] in [/home/runner/work/some_proj/some_dir] ...
  golangci-lint found no issues
  Ran golangci-lint in 3177ms

[SVilgelm]

PR is always welcome

[ldez]

The run.working-directory is only for steps with run.
The step with uses doesn't support it.

• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun
• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsworking-directory
• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunworking-directory

There is no way to get this information (it's neither inside the GitHub context nor inside the env vars)

So the only solution is to use with.working-directory.