Sync with playbooks: install-go-tools, gotestsum, and dynamic versions#192
Sync with playbooks: install-go-tools, gotestsum, and dynamic versions#192lieut-data merged 10 commits intomasterfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #192 +/- ##
======================================
Coverage 5.26% 5.26%
======================================
Files 3 3
Lines 38 38
======================================
Hits 2 2
Misses 36 36 ☔ View full report in Codecov by Sentry. |
cpoile
left a comment
There was a problem hiding this comment.
I think this is a good way to do it, nice!
build/manifest/main.go
Outdated
| // Update the manifest based on the state of the current commit | ||
| // Use the first version we find (to prevent causing errors) | ||
| var version string | ||
| tags := strings.Fields(BuildTagCurrent) | ||
| for _, t := range tags { | ||
| if strings.HasPrefix(t, "v") { | ||
| version = t | ||
| break | ||
| } | ||
| } | ||
| if version == "" { | ||
| if BuildTagLatest != "" { | ||
| version = BuildTagLatest + "+" + BuildHashShort | ||
| } else { | ||
| version = "v0.0.0+" + BuildHashShort | ||
| } | ||
| } | ||
| manifest.Version = strings.TrimPrefix(version, "v") | ||
|
|
||
| // Update the release notes url to point at the latest tag, if present. | ||
| if BuildTagLatest != "" { | ||
| manifest.ReleaseNotesURL = manifest.HomepageURL + "releases/tag/" + BuildTagLatest | ||
| } | ||
|
|
There was a problem hiding this comment.
LGTM 👍
If I understand correctly:
- if the current commit matches a tag, then we use that
- If not, use the latest tag and append the latest commit hash
- If no tag available, use
v0.0.0and append the latest commit hash
Co-authored-by: Michael Kochell <6913320+mickmister@users.noreply.github.com>
hanzei
left a comment
There was a problem hiding this comment.
Thanks for improving the starter template 🚀
| ## Install go tools | ||
| install-go-tools: | ||
| @echo Installing go tools | ||
| $(GO) install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.51.1 | ||
| $(GO) install gotest.tools/gotestsum@v1.7.0 |
There was a problem hiding this comment.
I really like that plugin now own the version of golangci-lint.
| ## Install go tools | ||
| install-go-tools: | ||
| @echo Installing go tools | ||
| $(GO) install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.51.1 |
There was a problem hiding this comment.
What is the impact of this change on CI? AFAIK it also installs a version of golangci-lint. Can we drop that?
There was a problem hiding this comment.
See below: uncertain how to roll out these changes to CI without breaking everything. For now, this at least gives the developer a reliable definition of the version in play. Thoughts?
| ## Runs any lints and unit tests defined for the server and webapp, if they exist, optimized | ||
| ## for a CI environment. | ||
| .PHONY: test-ci | ||
| test-ci: apply webapp/node_modules install-go-tools |
There was a problem hiding this comment.
Is there a follow up ticket to actually use the target in CI?
There was a problem hiding this comment.
Not at the moment, but I'm a bit blurry on how to achieve that -- it looks like we import @main, which would make whatever changes we add there affect all plugins at the same time, vs. plugins opting in to updated CI incrementally. Not sure how to crack this nut: thoughts?
There was a problem hiding this comment.
Maybe it's time to move to hand-picked CI versions. We have been bitten by the auto-update of @main way too often. Espcecially, updates to golangci-lint caused issues in the past.
cc @mickmister
There was a problem hiding this comment.
@mickmister Would you be open to owning that change? Brightscout could surely help with executing it.
hanzei
left a comment
There was a problem hiding this comment.
A few open discussion points, but nothing blocking
| ## Install go tools | ||
| install-go-tools: | ||
| @echo Installing go tools | ||
| $(GO) install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.51.1 |
There was a problem hiding this comment.
Do we actually need to install the binary? Or is
| $(GO) install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.51.1 | |
| $(GO) run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.51.1 |
enough?
There was a problem hiding this comment.
Well, the added duration comes from checking the remote go modules DB. The increase is similar running go install.
One downside of go run is, that it errors if the machine is offline.
There was a problem hiding this comment.
Ah, you're right: I wasn't comparing apples to apples as I thought!
| ## Runs any lints and unit tests defined for the server and webapp, if they exist, optimized | ||
| ## for a CI environment. | ||
| .PHONY: test-ci | ||
| test-ci: apply webapp/node_modules install-go-tools |
There was a problem hiding this comment.
Maybe it's time to move to hand-picked CI versions. We have been bitten by the auto-update of @main way too often. Espcecially, updates to golangci-lint caused issues in the past.
cc @mickmister

Summary
This brings into the starter-template a handful of changes originally introduced with Playbooks:
install-go-toolstarget that manages a local, versioned copy of anygo installed tools neededgotestsumfor improved go testing semanticsplugin.json, restoringmake apply, and shifting to a dynamically generated version number based on the nearest tag.This last point is easier explained by linking to the original PR: mattermost/mattermost-plugin-playbooks#433, but I note that the reason I reverted embedding
plugin.jsonis that this root file is no longer the final source of truth: rather, it's a (big) input into the final manifest that includes the dynamically generated version. Open to different approaches, but either way we don't have to care about checking in the generated manifests: they remain generated and.gitignored.In this repository, since we have yet to tag a version, any build will result in
v0.0.0+<commit hash>. Any build on a tagged version will bevX.Y.Zexactly. And any downstream commit from there would bevX.Y.Z+<short hash>until we tag a new version.Ticket Link
None.