-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync with playbooks: install-go-tools, gotestsum, and dynamic versions #192
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.0
and append the latest commit hash
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
Co-authored-by: Michael Kochell <6913320+mickmister@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a follow up ticket to actually use the target in CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mickmister Would you be open to owning that change? Brightscout could surely help with executing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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-tools
target that manages a local, versioned copy of anygo install
ed tools neededgotestsum
for 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.json
is 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.gitignore
d.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.Z
exactly. And any downstream commit from there would bevX.Y.Z+<short hash>
until we tag a new version.Ticket Link
None.