Attempting to fix the state of codecov action checks right now,
which are behaving very erratically.
Using the new functionality in Go 1.20 to merge multiple reports,
so now the unit & E2E coverage data reports are stored as artifacts
and then downloaded, merged, and finally uploaded to codecov as a
new job.
Additionally, add a `codecov.yml` config and try to turn down the
aggressiveness of it for CI checks.
Signed-off-by: Milas Bowman <[email protected]>
Instead of trying to make this work nicely cross-platform,
just push the Coverage logic into the GitHub Actions job,
as that's really where we care about it.
(It's surprisingly difficult to make this nicely portable;
to make PowerShell not error out if the path does not exist
you have to ignore ALL errors and the way that env vars are
passed to processes is not the same.)
Signed-off-by: Milas Bowman <[email protected]>
While this stripping does decrease the binary size by some amount, it also removes the ability for `govulncheck` (https://go.dev/blog/vuln) to scan the binary for actual uses of vulnerable functions, requiring the user to clone the code locally and hope they're testing against the same version of the stdlib, etc that the binary was built with. If we stop passing `-s`, then we can then run `govulncheck` on the binary directly (making it easier to flag both false positives in CVE scans _and_ actual issues worth looking into).
Here's an example of the output on a freshly built binary with this change:
```console
$ govulncheck ./bin/build/docker-compose
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.
Using [email protected] with
vulnerability data from https://vuln.go.dev (last modified 27 Feb 23 16:29 UTC).
Scanning your binary for known vulnerabilities...
No vulnerabilities found.
```
Compared to the 1.16.0 release binary:
```console
$ govulncheck ./docker-compose
go: downloading golang.org/x/vuln v0.0.0-20230224180816-edec1fb0a9c7
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.
Using [email protected] with
vulnerability data from https://vuln.go.dev (last modified 27 Feb 23 16:29 UTC).
Scanning your binary for known vulnerabilities...
govulncheck: vulncheck.Binary: reading go:func.*: no symbol "go:func.*"
```
It's not 100% apples-to-apples, but the size difference between these binaries is ~46MiB for the 1.16.0 release and ~52MiB for the binary I built from this commit.
Signed-off-by: Tianon Gravi <[email protected]>
I misunderstood the cause of the symptom in #10261 - thought that
we'd explicitly turned off CGO for Windows with some of the build
changes recently, but we don't even have `gcc` on the CI node, so
it's actually just `-race` entirely that's the trouble.
For right now, going the easy route and disabling it. We can look
at getting a C toolchain on the Windows machine later.
Signed-off-by: Milas Bowman <[email protected]>
```
go: -race requires cgo; enable cgo by setting CGO_ENABLED=1
```
We're explicitly using CGO on macOS now for FSEvents support and
purposefully NOT using CGO on other platforms since we don't need
it.
The race detector (`-race`) requires it, however, so for the e2e
make task, it should alway be on.
Signed-off-by: Milas Bowman <[email protected]>
This method looked slightly incomplete. If the port wasn't found,
it'd return `err`, but that was always `nil`, so we'd print out
`:0`.
Now, we construct a nice error message with the targeted port and
the ones we found.
The `--protocol` flag is also now case-insensitive to prevent any
weirdness/confusion there.
Co-authored-by: Nick Sieger <[email protected]>
Signed-off-by: Milas Bowman <[email protected]>
Fixes error when attempting to run `uname` on Windows, and add `.exe` to built binary on `make` if on Windows
Signed-off-by: Laura Brehm <[email protected]>
* update dockerfiles to use latest stable syntax
Some Dockerfiles were pinned to a minor release, which meant they
wouldn't be updated to get the latest stable syntax (and fixes),
and one Dockerfile used the "labs" variant to use the HEREDOC syntax,
which has now been promoted to the stable syntax.
* docs: rename Dockerfile
There's no other Dockerfiles in the same path, so the "docs"
prefix was redundant.
Signed-off-by: Sebastiaan van Stijn <[email protected]>
Guillaume Lours