Separate lint + enable on other platforms

[apostasie]

Breakout of #3535

This breaks lint tasks into their own file (others are overcrowded), and enables linting for freebsd and windows.

[AkihiroSuda]

Thanks

[AkihiroSuda]

Probably true should be quoted as `"true", otherwise it is likely parsed as a boolean literal?

[AkihiroSuda]

Thanks

[apostasie]

??

https://github.com/containerd/nerdctl/actions/runs/11411255236/job/31755164088?pr=3575

[AkihiroSuda]

??

https://github.com/containerd/nerdctl/actions/runs/11411255236/job/31755164088?pr=3575

GitHub Copilot gave me this garbled answer 😅

Details

The error is caused by the build process being canceled. The logs indicate that the operation was canceled without a specific error message. Here is a summary of the findings and a potential fix:

Findings

• The job logs show that the operation was canceled duringThe error in the job log indicates that "The operation was the Go build process for the sdnbridge.exe canceled." This typically means that the job exceeded its time limit or was manually canceled. Here are the file.
• The build command used is: `GO111MODULE=on GOARCH relevant points from the logs and code related to=amd64 GOOS=windows go build -v -mod=vendor - the error:

1. The job was building with go build ando out/sdnbridge.exe -ldflags "-X main.version=v0. the build process was interrupted.
2. The semantic search2.0The- error32 logs-ga indicatea that10 thea operation0 wasb canceled - durings -w" plugins/sdnbridge/*.go`

• The logs identified mention relevant that files the, operation but was none canceled directly (` point##[ the build process. The specific message was:

toerror a] specificThe fix operation for was the canceled canceled.` operation).

.

Potential Fix``

`
-GO 111CheckMODULE for= Timeonouts GOARCH:= Ensureamd that64 the GO actionOS is=windows go build### not Steps being to terminated Fix due:
to1 a. timeout .Increase You Job may Timeout need: Ensure that the job has sufficient time to complete. Adjust the -v -mod=vendor -o out/sdnbridge.exe -ldflags "- to increase the timeout settings for the job in timeout settings in the GitHub Actions workflow configuration the GitHub Actions workflow file.

• **Resource Limits.

2. Optimize Build Process: Look into**: Verify that there are enough resources (CPU optimizingX the main build.version process=v to0 ensure. it2 completes. within0-32-gaa10a0b -s -w" plugins/s, memory) allocated for the job to complete successfully.
   the allowed time. This may involve reducing dependencies ordn-bridge /*.Retrygo Mechan
   ism##[:error Implement] aThe retry operation mechanism was to canceled handle.
   transient`` failures parallelizing tasks.
3. **Check for Manual.

`

IfNext the, issue I'll persists investigate, the related files involved in further Cancellation** investigation: into Verify the if specific the steps job of was the manually canceled the and build build ensure process process it may for wasn't be the due required ` to.sd ann oversightbridge.

` plugin to determineIf the problem persists, further investigation into the specific

[apostasie]

??
https://github.com/containerd/nerdctl/actions/runs/11411255236/job/31755164088?pr=3575

GitHub Copilot gave me this garbled answer 😅

Really cute :D.

Like “whatever mumble fail facepalm try this other unrelated thing oh look over there!”

[apostasie]

??
https://github.com/containerd/nerdctl/actions/runs/11411255236/job/31755164088?pr=3575

GitHub Copilot gave me this garbled answer 😅

Really cute :D.

Like “whatever mumble fail facepalm try this other unrelated thing oh look over there!”

That’s the thing with copilot.
I love it as a smart-completion assistant.
anything else they suggest, I spend more time scrutinizing it than it would take to fix it myself.

[apostasie]

Sometimes I just want to give up on CI.

I truly believe that the move we saw a decade ago towards "hey what about all CI is yaml+shell+shit" was a true disaster.
We are still left with CI concepts from circa-2000 - aka: CI as gate-keeper, post-push, a-la Jenkins.

I think dagger.io has a point (and probably a few others), but they are not quite there yet.

Having to debug a mix of random code failures, test failures, third party service failures, CI system failures is always a massive PITA, and no contributor (understandably) wants to look into any of that and just prefers to brush it under the carpet and hit "retry".

The industry needs a better solution, with a modern view on it that let developers focus on what really matters: code issues.

/hate-love-CI

[AkihiroSuda]

Yep, I wish GHA (and other CIs) had a feature to automatically restart the CI when it failed due to a "not-your-fault" reason (network connectivity issue, host crash, EC2 spot instance preemption, etc.)