How to run on multiple directories #271
Labels
question
Further information is requested
Comments
|
I also have this question. We have a mixed codebase like: Currently, we run linting locally with a command like this from the 'Go' directory: I have tried a few times to set it up in a better way but I always end up hitting the 'there are no go files error'. Is there a way to install this action (so we get all the right installations and caches) but use a custom command to run? |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Finally, I found out how. tl; drYou need to place them in the ts; drgolangci-lint run --config ./.github/golangci.yml ./... ./_example/dir1 ./_alt/dir2The above case will be: name: golangci-lint
on:
workflow_dispatch:
pull_request:
branches:
- main
jobs:
golangci:
name: lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: golangci-lint
uses: golangci/golangci-lint-action@v3
with:
version: latest
args: --config ./.github/golangci.yml ./... ./_example/dir1 ./_alt/dir2 |
|
@KEINOS I thought that the |
|
I thought so too. But since the directory begins with "_", it omits from "./..." unless specifying them. It took me time to find it out. |
|
FYI - just ran in to this issue again. Easiest workaround we found was to pass |
|
this is on topic as it gets (daily user) |
|
@serbrech -- but it does not :D |
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 25, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. [1] golangci/golangci-lint-action#271
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 25, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. [1] golangci/golangci-lint-action#271
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 25, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. Also, I notice that the lints/tests in `Makefile` had been commented out for `./cmd/river` for some reason (maybe something I did during the driver refactor and forgot to fix), so I uncommented them. [1] golangci/golangci-lint-action#271
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 25, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. Also, I notice that the lints/tests in `Makefile` had been commented out for `./cmd/river` for some reason (maybe something I did during the driver refactor and forgot to fix), so I uncommented them. [1] golangci/golangci-lint-action#271
|
We needed to be able to do this on multiple Go modules that we have in the same repository. The trick of passing Chris' answer above to configure golangci-lint's GitHub Action with - name: Lint
uses: golangci/golangci-lint-action@v4
with:
# golangci-lint needs to be run separately for every Go module, and
# its GitHub Action doesn't provide any way to do that. Have it fetch
# the golangci-lint binary, trick it into not running by sending only
# `--help`, then run the full set of lints below. DO NOT run separate
# modules as separate golangci-lint-action steps. Its post run caching
# can be extremely slow, and that's amplified in a very painful way if
# it needs to be run multiple times.
args: --help
version: ${{ env.GOLANGCI_LINT_VERSION }}
- name: Run lint
run: make lintWith our make target being: .PHONY: lint
lint:
cd . && golangci-lint run --fix
cd cmd/river && golangci-lint run --fix
cd riverdriver && golangci-lint run --fix
cd riverdriver/riverdatabasesql && golangci-lint run --fix
cd riverdriver/riverpgxv5 && golangci-lint run --fix
cd rivertype && golangci-lint run --fixA side effect is that it no longer annotates the GitHub PR with lint failures like the GitHub Action step would ( |
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 25, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. I think what might've been happening is that each lint job was overwriting the last job's cache, which is why each post run step seemed to be doing so much work. I didn't validate this hypothesis, but it seems like a strong possibility. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. Also, I notice that the lints/tests in `Makefile` had been commented out for `./cmd/river` for some reason (maybe something I did during the driver refactor and forgot to fix), so I uncommented them. [1] golangci/golangci-lint-action#271
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 25, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. I think what might've been happening is that each lint job was overwriting the last job's cache, which is why each post run step seemed to be doing so much work. I didn't validate this hypothesis, but it seems like a strong possibility. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. Also, I notice that the lints/tests in `Makefile` had been commented out for `./cmd/river` for some reason (maybe something I did during the driver refactor and forgot to fix), so I uncommented them. [1] golangci/golangci-lint-action#271
brandur
added a commit
to riverqueue/river
that referenced
this issue
Feb 29, 2024
Like with running Go tests, the lints for each separate Go module must be running separately. This is currently being accomplished in CI by giving each Go module its own lint job using golangci-lint's GitHub Action. Unfortunately, this is really not working out well. Although the lints themselves are all very fast to run (just a couple seconds), the post run step where it saves it cache is quite slow, about two minutes, and that's happening for each of the lint steps, making the entire lint job take almost _ten minutes_ to run. I think what might've been happening is that each lint job was overwriting the last job's cache, which is why each post run step seemed to be doing so much work. I didn't validate this hypothesis, but it seems like a strong possibility. Here, try to hack around the problem by having the main lint job fetch golangci-lint, but then only run `--help`, and then do the real linting as a separate step (one that doesn't use the GitHub Action) that calls into our `make lint` target to run lints for each Go module. A downside is that it may not annotate lint problems on the GitHub PR, which is something that theoretically happened before, although it never seemed to work for me. This might not be that bad though because it could as a side effect improve the log output, which is terrible for the GitHub Action step because it doesn't include files or line numbers. Also, I notice that the lints/tests in `Makefile` had been commented out for `./cmd/river` for some reason (maybe something I did during the driver refactor and forgot to fix), so I uncommented them. [1] golangci/golangci-lint-action#271
|
duplicate of #74 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a monorepo and want run linter on
dir1anddir2. How can I do it?doesn't work:
The text was updated successfully, but these errors were encountered: