Michael Pearson

Taking a quick look at this this morning (as this has also started hitting me in vscode): * it's specific to the new implementation that uses golang.org/x/tools/go/packages * the new...

Okay. Deleting `godef` and then rebuilding it with `go get` bumps the execution back up to 2s, which then drops to 0.7s on subsequent runs. It is definitely slower when...

Confirming: If I put `grpc-health-probe` in my GOPATH, then remove its go.mod/go.sum files, I get consistent < 0.1s times regardless of whether it's my first run of that godef binary...

A half-day of deep diving later: 1. `godef` uses `golang.org/x/tools/go/packages` in directories containing a `go.mod` to resolve things as gomodules make things non-trivial 1. `packages` calls out to `go list`...

Assuming that this runs on every step, how much time will checking that the tag/brach is up to date over multiple plugins take? Github can be .. slow, sometimes.

... if it's done inside agent (ie, in Go), could be easily done in parallel. (and I wonder if a similar thing can be done with the s3 secrets plugin...

This makes sense. Would it still check for an update if pinned to a tag (or other ref that isn't a commit hash)? Not a use case we have right...

Yep - so, same question as above, but they've specified a branch id - the refresh once-per-hour behaviour would apply?

I'd err on not treating tags as immutable, personally, in large part because git doesn't. You've then got a solid split between "refs that are immutable" (commit hashes) and "refs...

TIL. I had a mental model in my head that tags were easily mutable which was not correct, as you've shown. :)