-
Notifications
You must be signed in to change notification settings - Fork 132
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
Server-like make build
and ensuring builds are clean in CI
#1329
Conversation
Probably should've done this a while ago, but the sooner the better.
make build
and ensuring builds are clean in CI
Codecov Report
Additional details and impacted filesContinue to review full report in Codecov by Sentry.
|
…lt, but does not print error messages it encounters
…/bin/true: no such file or directory
This reverts commit 6ec6aa8.
build: $(BUILD)/fmt ## ensure all packages build | ||
go build ./... | ||
$Q # caution: some errors are reported on stdout for some reason | ||
go test -exec true ./... >/dev/null |
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.
any reason for >/dev/null here?
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.
Just that it's quite noisy, printing every package at it builds it, and somewhat misleading as it looks like test runs but it didn't run any actual tests.
(same reasons as for the server)
# intentionally capture stderr, so status-errors are also PR-failing. | ||
# in particular this catches "dubious ownership" failures, which otherwise | ||
# do not fail this check and the $() hides the exit code. | ||
if [ -n "$(git status --porcelain 2>&1)" ]; then |
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.
nit: generally prefer [[
and it's not needed, but also set -o pipefail
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'm pretty sure I do still need to capture output with $()
, and bash / [[
don't change this semantic in that sense... but this is more than niche enough that I haven't actually tried it so now I'm curious. let's see what happens.
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.
... and I'm struggling to reproduce exactly what I thought I remembered 🤔
I might be getting it mixed up with how export x=$(...)
behaves too (as that also suppresses failures).
gonna just stick with what the server does here since it's reasonably well proven over there, and also seems to work correctly here. and that way they're at least consistent and the path to fix/improve if we do find something conclusive is obvious.
bash + pipefail does seem promising enough to check at another time though.
@@ -0,0 +1,18 @@ | |||
#!/bin/sh |
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.
shouldn't this be /bin/bash
?
In this, the year of 50 of Mechagodzilla's incarnation, is there any reason to still use shell?
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.
this is basically just copying from github.com/uber/cadence so any change we'd apply here we should probably keep in sync.
but: agreed! though this is mostly executed in docker, and docker is less likely to have bash for space reasons. I suspect our buildkite does have bash installed, but it's not quite a practical guarantee like it is on developer machines.
@@ -1,35 +0,0 @@ | |||
// Copyright (c) 2017 Uber Technologies, Inc. |
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.
no longer necessary at all - go build ./...
is much better proof of build-ability.
pipefail
test
last try
sh check
no pipefail til
going back to before, really not sure any more how bash / sh / $() work. so match the server setup so we at least have the same behavior (which is reasonably well tested both there and here), and fixing both will be easier if needed.
@@ -165,10 +164,6 @@ $(BIN)/mockery: internal/tools/go.mod | |||
$(BIN)/copyright: internal/cmd/tools/copyright/licensegen.go | |||
go build -mod=readonly -o $@ ./internal/cmd/tools/copyright/licensegen.go | |||
|
|||
# dummy binary that ensures most/all packages build, without needing to wait for tests. | |||
$(BUILD)/dummy: $(ALL_SRC) $(BUILD)/go_mod_check | |||
go build -mod=readonly -o $@ internal/cmd/dummy/dummy.go |
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.
go build ./...
does this same check substantially better
restore safe.directory
There's more work to be done, but it's a major step towards forcing stability.
Oddly, missing the safe.directory git setting leads to Go failing to get version info, leading to errors building, but for some reason it doesn't show the error that git's reporting (missing safe directory). Just stuff like this with no other output:
Once I fixed that, I learned that
go test -exec nonexistent ./... >/dev/null
errors, but the "FAIL: command nonexistent not found" error is.... reported on stdout, so it's hidden.And so is the "FAIL the/package/name" message.
But if you have a failing build, the failure is printed to stderr:
I have no idea why
-exec nonexistent
isn't on stderr, but I left a comment in the makefile anyway.Quite a large amount of weird stuff condensed into a seemingly simple goal.