Noticed a hiccup a few times while working up the pr for a new module in that occasionally the go running would take a long time to process its lint check. Looking deeper into this I see this run through the process:
Sample from recent run which exited:
...
find tests/ -name '*.go' | grep -q '\.go' || exit 0; golangci-lint run -c .golangci.yaml --timeout 5m -v ./tests/...;
level=info msg="golangci-lint has version 2.6.2 built with go1.25.3 from dc16cf43 on 2025-11-14T13:00:52Z"
level=info msg="[config_reader] Used config file components/module/linkfiles/.golangci.yaml"
level=info msg="[config_reader] Module name \"github.com/launchbynttdata/*************************\""
level=info msg="maxprocs: Leaving GOMAXPROCS=2: CPU quota undefined"
level=info msg="[goenv] Read go env for 19.856117ms: map[string]string{\"GOCACHE\":\"/home/runner/.cache/go-build\", \"GOROOT\":\"/home/runner/.asdf/installs/golang/1.25.4/go\"}"
level=info msg="[lintersdb] Active 5 linters: [errcheck govet ineffassign staticcheck unused]"
level=info msg="[loader] Go packages loading at mode 8767 (compiled_files|files|types_sizes|deps|exports_file|imports|name) took 4m14.80065992s"
level=info msg="[runner/filename_unadjuster] Pre-built 0 adjustments in 4.129537ms"
level=info msg="Memory: 3001 samples, avg is 196.6MB, max is 2793.0MB"
level=info msg="Execution took 5m0.008186117s"
level=info msg="[linters_context/goanalysis] analyzers took 1m38.776791187s with top 10 stages: buildir: 1m26.557529691s, inspect: 2.60086478s, nilness: 1.84720231s, ctrlflow: 1.809562689s, printf: 1.727939547s, fact_purity: 1.321124433s, fact_deprecated: 1.000679932s, SA5012: 914.12578ms, typedness: 813.330654ms, tokenfileanalyzer: 150.350252ms"
level=info msg="[runner] processing took 4.74µs with stages: max_same_issues: 952ns, exclusion_paths: 611ns, exclusion_rules: 461ns, path_absoluter: 411ns, nolint_filter: 281ns, max_from_linter: 211ns, source_code: 210ns, sort_results: 180ns, diff: 171ns, path_relativity: 170ns, invalid_issue: 170ns, fixer: 161ns, path_shortener: 160ns, max_per_file_from_linter: 151ns, filename_unadjuster: 140ns, path_prettifier: 80ns, generated_file_filter: 60ns, cgo: 60ns, severity-rules: 50ns, uniq_by_line: 50ns"
level=info msg="[runner] linters took 1m2.534200038s with stages: goanalysis_metalinter: 1m2.533111615s"
level=info msg="File cache stats: 0 entries of total size 0B"
0 issues.
level=error msg="Timeout exceeded: try increasing it by passing --timeout option"
make[1]: *** [components/module/tasks/golang/Makefile:80: go/lint] Error 4
make[1]: Leaving directory '/home/runner/work/*************************/*************************'
make: *** [components/module/tasks/golang/Makefile:92: lint] Error 2
Error: Process completed with exit code 2.
I had believed at the time this would get handled by the .golangci.yaml present in the root of the repo from the make configure build of the repo itself:
version: "2"
run:
# Timeout for analysis, e.g. 30s, 5m.
timeout: 10m # moved to 10 min due to length of time that runners were taking to check
allow-parallel-runners: true
However, relevant to the overall command run golangci-lint run -c .golangci.yaml --timeout 5m -v ./tests/... from the golangci-lint docs:
The config file has lower priority than command-line options. If the same bool/string/int option is provided on the command-line and in the config file, the option from command-line will be used. Slice options (e.g. list of enabled/disabled linters) are combined from the command-line and config file.
Relevant to this codebase I am recommending that the inputs be pulled through from the make files referenced (within the scope of NTT/Launch at least). This exposure would allow for someone to add into the pull-request-terraform-check.yml something like the following:
Current/original:
...
jobs:
check:
name: "Check AWS Terraform Code"
...
uses: launchbynttdata/launch-workflows/.github/workflows/reusable-terraform-check-aws.yml@0.11.0
with:
assume_role_arn: ${{ vars.TERRAFORM_CHECK_AWS_ASSUME_ROLE_ARN }}
region: ${{ vars.TERRAFORM_CHECK_AWS_REGION }}
...
Updated timeout variable:
...
jobs:
check:
name: "Check AWS Terraform Code"
...
uses: launchbynttdata/launch-workflows/.github/workflows/reusable-terraform-check-aws.yml@0.11.0
with:
assume_role_arn: ${{ vars.TERRAFORM_CHECK_AWS_ASSUME_ROLE_ARN }}
region: ${{ vars.TERRAFORM_CHECK_AWS_REGION }}
go_lint_timeout: 30m
...
In which go_lint_timeout would be set to input 30m
Possibly current as:
- name: "make lint"
run: |
make lint
Could have something similar to:
- name: "make lint"
run: |
make lint
with:
go_lint_timeout: ${{ inputs.go_lint_timeout }}
go_test_timeout: ${{ inputs.go_test_timeout }}
This could handle these while providing some backwards compatibility with the existing downstream items.
Noticed a hiccup a few times while working up the pr for a new module in that occasionally the go running would take a long time to process its lint check. Looking deeper into this I see this run through the process:
Sample from recent run which exited:
I had believed at the time this would get handled by the .golangci.yaml present in the root of the repo from the make configure build of the repo itself:
However, relevant to the overall command run
golangci-lint run -c .golangci.yaml --timeout 5m -v ./tests/...from the golangci-lint docs:Relevant to this codebase I am recommending that the inputs be pulled through from the make files referenced (within the scope of NTT/Launch at least). This exposure would allow for someone to add into the pull-request-terraform-check.yml something like the following:
Current/original:
Updated timeout variable:
In which go_lint_timeout would be set to input 30m
Possibly current as:
Could have something similar to:
This could handle these while providing some backwards compatibility with the existing downstream items.