search

atc0005 / shared-project-resources

Shared workflows and tooling for projects that I maintain
MIT License
1 stars 0 forks source link

Pull Makefile-initiated linting checks *or* move to a monthly schedule #149

Open atc0005 opened 1 year ago

atc0005 commented 1 year ago

Overview

The recent bug with the v2.17.0 release of the gosec linter (bundled with golangci-lint v1.54.2) triggered false-positive linting failures across several projects using the workflows from this repo.

The go-ci based containers were updated to rollback golangci-lint to v1.54.1 which resolved the container based linting false-positives.

The linting jobs using project Makefiles however continue to fail. This is because of two reasons:

  1. The project Makefiles install the latest stable release of golangci-lint
  2. The upstream project does not appear to (quickly?) rollback bundled linters when a confirmed problem exists
    • the project appears to primarily wait on their upstream sources to resolve the problem before generating a new release

I originally intended for the Makefiles to serve two purposes:

I still use project Makefiles to generate assets (mostly using containers now), but no longer use Makefiles for local linting tasks.

As noted in the GH issue title, it's probably worth first dropping the Makefile linting checks as regular CI jobs. To begin with I'd add them to the monthly scheduled tasks, but might end up dropping them entirely, leaving them in the Makefile but generally disused.

TODO

Projects to update

Drop branch protection rule requirement for the Makefile / Lint codebase using Makefile status check:

atc0005 commented 1 year ago

Looking over the current setup the easiest path forward is to mark the job as optional just like the Makefile / Build codebase using Makefile all recipe has been marked. That job is then explicitly enabled for the monthly scheduled workflow.

atc0005 commented 8 months ago
  • Consider removing CI Makefile-initiated linting tasks

I'm thinking that by keeping this limited to a monthly schedule it remains useful as a proof against Makefiles "degrading" and no longer properly running the linting tasks.

  • might be worth dropping project-specific linting configuration?

This is worth considering. Since we're using the go-ci project images which bundle a standardized golangci-lint config file we don't necessarily need project-specific config files unless those config files apply stricter linting standards than the standardized linter config.

Said another way, if we remove the linter config file from each project we should probably also remove the Makefile-initiated linting tasks from CI (currently a monthly schedule).

For now, it's probably worth leaving everything as it is until I think on this further.

atc0005 commented 8 months ago

So to recap, next steps would include (if at all):