Goals:

• keep in sync with "stable", "oldstable" variants
• enable "unstable" container specific linters for testing prior to enabling within "stable" and "oldstable" variants

See also #50.

Per https://docs.docker.com/engine/reference/builder/#env:

The ENV instruction also allows an alternative syntax ENV , omitting the =. For example:

ENV MY_VAR my-value

This syntax does not allow for multiple environment-variables to be set in a single ENV instruction, and can be confusing. For example, the following sets a single environment variable (ONE) with value "TWO= THREE=world":

ENV ONE TWO= THREE=world

The alternative syntax is supported for backward compatibility, but discouraged for the reasons outlined above, and may be removed in a future release.

Suggested fix from GH user jurre:

    ignore:
      - dependency-name: "golang"
-       versions: ["1.15.x"]
+       versions: ["1.15"]

refs dependabot/dependabot-core#2644 (comment)

https://github.com/mgechev/revive

Time to update Docker containers to these release versions.

Docker examples:

• https://github.com/golangci/golangci-lint/blob/cb2f12e7e19e2f65bdfd136685a3c70c2f1e2adf/.github/dependabot.yml
• https://github.com/PowerShell/PowerShell-Docker/blob/190a95362ae0d936116133bc3ea247f253a77dba/.github/dependabot.yml

I optimistically tagged the work for v0.2.15 without going through a full image set rebuild first. One of the "locked" dependencies for the Alpine containers failed to install, failing the Alpine build container builds:

Building stable-alpine-build.x64 release
sudo docker build \
	--no-cache \
	--file stable/Dockerfile.alpine-build.x64 \
	stable/ \
	-t registry-1.docker.io/atc0005/go-ci:go-ci-stable-alpine-buildx64 \
	-t registry-1.docker.io/atc0005/go-ci:go-ci-stable-alpine-buildx64-v0.2.15-0-g8b32c4f \
	--label=atc0005.go-ci
Sending build context to Docker daemon  16.38kB
Step 1/12 : FROM golang:1.15.5-alpine3.12
 ---> 1de1afaeaa9a
Step 2/12 : ENV APK_GCC_MINGW64_VERSION="9.3.0-r0"
 ---> Running in 8a7804a2e5d7
Removing intermediate container 8a7804a2e5d7
 ---> a68e52309113
Step 3/12 : ENV APK_BASH_VERSION="5.0.17-r0"
 ---> Running in 5081df87b19c
Removing intermediate container 5081df87b19c
 ---> 86e12af62599
Step 4/12 : ENV APK_GCC_VERSION="9.3.0-r2"
 ---> Running in c567e933ef68
Removing intermediate container c567e933ef68
 ---> 08ab67bcbc84
Step 5/12 : ENV APK_GIT_VERSION="2.26.2-r0"
 ---> Running in ae366ca5801e
Removing intermediate container ae366ca5801e
 ---> a894f495e3eb
Step 6/12 : ENV APK_MAKE_VERSION="4.3-r0"
 ---> Running in 9714bff9e797
Removing intermediate container 9714bff9e797
 ---> ce80d8b99ef5
Step 7/12 : ENV APK_UTIL_LINUX_VERSION="2.35.2-r0"
 ---> Running in 953416e170db
Removing intermediate container 953416e170db
 ---> 08523b4b6a8e
Step 8/12 : ENV APK_FILE_VERSION="5.38-r0"
 ---> Running in 262bdb64e9a6
Removing intermediate container 262bdb64e9a6
 ---> cf6030a195f2
Step 9/12 : ENV APK_NANO_VERSION="4.9.3-r0"
 ---> Running in 71e4e2674941
Removing intermediate container 71e4e2674941
 ---> 98ae10b173ef
Step 10/12 : ENV APK_MUSL_DEV_VERSION="1.1.24-r9"
 ---> Running in 43f5000bf458
Removing intermediate container 43f5000bf458
 ---> 615ace1f25e7
Step 11/12 : RUN apk add --no-cache     make=${APK_MAKE_VERSION}     bash=${APK_BASH_VERSION}     util-linux=${APK_UTIL_LINUX_VERSION}     git=${APK_GIT_VERSION}     gcc=${APK_GCC_VERSION}     musl-dev=${APK_MUSL_DEV_VERSION}     mingw-w64-gcc=${APK_GCC_MINGW64_VERSION}     nano=${APK_NANO_VERSION}     file=${APK_FILE_VERSION}
 ---> Running in 2f48bd17e2b1
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
ERROR: unsatisfiable constraints:
  musl-dev-1.1.24-r10:
    breaks: world[musl-dev=1.1.24-r9]
The command '/bin/sh -c apk add --no-cache     make=${APK_MAKE_VERSION}     bash=${APK_BASH_VERSION}     util-linux=${APK_UTIL_LINUX_VERSION}     git=${APK_GIT_VERSION}     gcc=${APK_GCC_VERSION}     musl-dev=${APK_MUSL_DEV_VERSION}     mingw-w64-gcc=${APK_GCC_MINGW64_VERSION}     nano=${APK_NANO_VERSION}     file=${APK_FILE_VERSION}' returned a non-zero code: 1
Makefile:69: recipe for target 'build' failed
make: *** [build] Error 1

Hi gophers,

We have just released Go 1.14.7 and Go 1.13.15 to address a recently reported security issue. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.14.7).
encoding/binary: ReadUvarint and ReadVarint can read an unlimited number of bytes from invalid inputs
Certain invalid inputs to ReadUvarint or ReadVarint could cause those functions to read an unlimited number of bytes from the ByteReader argument before returning an error. This could lead to processing more input than expected when the caller is reading directly from a network and depends on ReadUvarint and ReadVarint only consuming a small, bounded number of bytes, even from invalid inputs.

With the update, ReadUvarint and ReadVarint now always return after consuming a bounded number of bytes (specifically, MaxVarintLen64, which is 10). The result being returned has not changed; the functions merely detect and return some errors without reading as much input.

Thanks to Diederik Loerakker, Jonny Rhea, Raúl Kripalani, and Preston Van Loon for reporting this issue.

This issue is CVE-2020-16845 and Go issue golang.org/issue/40618.

The upcoming Go 1.15rc2 release will also include the fix above.

Downloads are available at https://golang.org/dl for all supported platforms.

Thank you,
Katie and Filippo on behalf of the Go team

refs https://groups.google.com/forum/#!topic/golang-announce/NyPIaucMgXo

• https://taplo.tamasfe.dev/cli/#installation
• tamasfe/taplo i33

Need to refresh oldstable to use Go 1.14 and stable to use the new Go 1.15 version.

References to Go 1.13 can be removed entirely.

The Go 1.15rc2-based unstable container ... I'm not sure. It may have to stay as-is until the next official RC is available? Another approach would be to push new, lightly tested (or even entirely untested) changes out via this container.

https://github.com/leighmcculloch/gochecknoglobals

Check that no globals are present in Go code.

Why

Global variables are an input to functions that is not visible in the functions signature, complicate testing, reduces readability and increase the complexity of code.

https://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html https://twitter.com/davecheney/status/871939730761547776

Quay.io?

https://quay.io/plans/

https://github.com/golangci/golangci-lint/releases/tag/v1.32.0

semgrep-go is a collection of static analysis rules for Go code that pick up common errors or potential mistakes: fmt.Sprintf() instead of net.JoinHostPort(), parsed int64s downcast to int32, detecting net.ErrClosed with strings.Contains(), and many more

refs:

• https://github.com/quasilyte/go-ruleguard
• https://semgrep.dev/
• https://github.com/dgryski/semgrep-go
• https://twitter.com/bitfield/status/1333806836856786944

https://github.com/golangci/golangci-lint/releases/tag/v1.33.0

TL;DR: at Orijtech, Inc., we’ve developed a first of its kind static analyzer, “structslop” that examines and recommends optimal struct field arrangements in your Go programs; it’ll help you reduce RAM consumed by offending structs, making your programs more efficient! High performance systems require efficiency in every aspect, and our work can help out!

• https://medium.com/orijtech-developers/efficient-struct-packing-guided-pass-for-go-92255872ec72
• https://github.com/orijtech/structslop

https://github.com/psampaz/gothanks

Doesn't seem like it would be useful as a CI/CD tool in its current state, but perhaps later on.

https://github.com/leighmcculloch/gochecknoinits

Check that no inits functions are present in Go code.

Why

Init functions cause an import to have side effects, and side effects are hard to test, reduce readability and increase the complexity of code.

https://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html https://twitter.com/davecheney/status/871939730761547776

Description:

Cyber Monday ended, but to sweeten Go programming for you, we've open sourced and donated a static analyzer "sigchanyzer" that'll catch bugs from potentially loss of signals in UNIX programs from use of unbuffered channels with signal.Notify

refs:

• https://twitter.com/orijtech/status/1333726361458864128
• https://twitter.com/odeke_et/status/1333737132070895617
• https://github.com/orijtech/sigchanyzer
• golang/go#9399
• https://go-review.googlesource.com/c/go/+/274332

I followed the directions for publishing packages here by creating a Personal Access Token, then logging in with the local Docker daemon on my test VM. That worked fine and I was able to build and upload container images to docker.pkg.github.com.

I then updated a test workflow file in the atc0005/dnsc project to use the container image. This failed at the Initialize containers step:

##[error]Docker pull failed with exit code 1
/usr/bin/docker version --format '{{.Server.APIVersion}}'
'1.40'
Docker daemon API version: '1.40'
/usr/bin/docker version --format '{{.Client.APIVersion}}'
'1.40'
Docker client API version: '1.40'
/usr/bin/docker ps --all --quiet --no-trunc --filter "label=87c201"
/usr/bin/docker network prune --force --filter "label=87c201"
/usr/bin/docker network create --label 87c201 github_network_ce8740c1cecc40499ef90336213d1f90
a3d668d503c5b6f2fa5a6874eee818b1942e836ed75b2a0254f78ccb746bc2ee
/usr/bin/docker pull docker.pkg.github.com/atc0005/go-ci/go-ci-stable:latest
Error response from daemon: Get https://docker.pkg.github.com/v2/atc0005/go-ci/go-ci-stable/manifests/latest: no basic auth credentials
##[warning]Docker pull failed with exit code 1, back off 3.496 seconds before retry.
/usr/bin/docker pull docker.pkg.github.com/atc0005/go-ci/go-ci-stable:latest
Error response from daemon: Get https://docker.pkg.github.com/v2/atc0005/go-ci/go-ci-stable/manifests/latest: no basic auth credentials
##[warning]Docker pull failed with exit code 1, back off 2.853 seconds before retry.
/usr/bin/docker pull docker.pkg.github.com/atc0005/go-ci/go-ci-stable:latest
Error response from daemon: Get https://docker.pkg.github.com/v2/atc0005/go-ci/go-ci-stable/manifests/latest: no basic auth credentials
##[error]Docker pull failed with exit code 1

I'm still digging, but it appears that using containers in this way may not be supported?

• https://github.community/t/docker-pull-from-public-github-package-registry-fail-with-no-basic-auth-credentials-error/16358
• https://github.community/t/docker-from-within-actions/122602
• containerd/containerd#3291

Still digging, but if this is the case, I'll need to abandon publishing efforts to the GitHub Packages repos and instead push to Docker Hub, quay.io or another Docker image repo.

This looks promising:

https://github.com/hadolint/hadolint

This can serve as a quick reference to what version of what tool is included in each image. The Dockerfiles are the authoritative reference, but having a quick reference should be useful.

https://github.com/mfridman/tparse

One for way down the line once I've learned how to implement proper testing for the codebase. Figured it was worth noting now.

See GH-41 and GH-42.

I expect that this release will drop "soon".

Create a demo/test Go app with dependencies on all Go tooling used by the Docker images created from this rep.

Examples:

• https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module
• https://github.com/golangci/golangci-lint/blob/master/tools/
  • https://github.com/golangci/golangci-lint/blob/master/tools/tools.go
  • https://github.com/golangci/golangci-lint/blob/master/tools/go.mod

An easy way to find outdated dependencies of your Go projects.

go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.

refs: https://github.com/psampaz/go-mod-outdated

The current images weigh in at 852 MB each. While useful build environments, most of that is not needed for linting-only purposes. Instead of using the official golang images as the base, I should use multi-stage image builds and have the final image based off of Alpine Linux (which is a great deal smaller).

References:

• https://fabianlee.org/2020/01/26/golang-using-multi-stage-builds-to-create-clean-docker-images/
• https://github.com/fabianlee/golang-memtest/blob/master/Dockerfile

Goals:

• bundle .golangci.yml as a default config file for golangci-lint
• bundle .markdownlint.yml as a default config file for markdownlint
• allow easy override for either if the project using these containers has their own copy of either file

https://github.com/golangci/golangci-lint/releases/tag/v1.32.2

Put together enough notes that it feels "good enough" for a v0.1.0 release/tag. After that, republish the Docker images. Circle back later and start work to integrate this repo and the Docker Hub image repo.

Ariadne Conill (2):
main/musl: security fix for CVE-2020-28928
main/tzdata: switch to fat format

refs https://alpinelinux.org/posts/Alpine-3.12.2-released.html

From a CI run:

Run /golangci-lint run -v
level=info msg="[config_reader] Config search paths: [./ /__w/dnsc/dnsc /__w/dnsc /__w /]"
level=info msg="[config_reader] Used config file .golangci.yml"
level=warning msg="Failed to discover go env: failed to run 'go env': exec: \"go\": executable file not found in $PATH"
level=info msg="[lintersdb] Active 25 linters: [deadcode depguard dogsled dupl errcheck goconst gocritic gofmt goimports golint gosec gosimple govet ineffassign maligned misspell prealloc scopelint staticcheck structcheck stylecheck typecheck unconvert unused varcheck]"
level=info msg="[loader] Go packages loading at mode 575 (compiled_files|exports_file|imports|types_sizes|deps|files|name) took 158.605µs"
level=error msg="Running error: context loading failed: failed to load packages: failed to load with go/packages: 'go list' driver requires 'go', but executable file not found in $PATH"
level=info msg="Memory: 2 samples, avg is 69.6MB, max is 69.6MB"
level=info msg="Execution took 1.68565ms"
##[error]Process completed with exit code 3.

Relevant portion of the configuration currently used by the atc0005/go-teams-notify project (inherited from the dasrick/go-teams-notify project):

linters:
  enable:
    - gocognit
    - gocyclo

linters-settings:
  gocognit:
    # minimal code complexity to report, 30 by default (but we recommend 10-20)
    min-complexity: 10

  gocyclo:
    # minimal code complexity to report, 30 by default (but we recommend 10-20)
    min-complexity: 15

https://github.com/todogroup/repolinter

Example checks:

git clone https://github.com/todogroup/repolinter
npx repolinter
✔ license-file-exists: found (LICENSE)
✔ readme-file-exists: found (README.md)
✔ contributing-file-exists: found (CONTRIBUTING)
✔ code-of-conduct-file-exists: found (CODE-OF-CONDUCT)
✔ changelog-file-exists: found (CHANGELOG)
✔ readme-references-license: File README.md contains license
✔ binaries-not-present: Excluded file type doesn't exist (**/*.exe,**/*.dll)
✔ license-detectable-by-licensee: Licensee identified the license for project: Apache License 2.0
✔ test-directory-exists: found (tests)
✔ integrates-with-ci: found (.travis.yml)
✔ source-license-headers-exist: The first 5 lines of 'index.js' contain all of the requested patterns.
...
✔ github-issue-template-exists: found (ISSUE_TEMPLATE)
✔ github-pull-request-template-exists: found (PULL_REQUEST_TEMPLATE)
✔ package-metadata-exists: found (Gemfile)
✔ package-metadata-exists: found (package.json)

This could help protect against the accidental loss of important files (e.g., README, license file) and if kept up to date could flag new best practice failures.

Further research is needed to determine how flexible the linting rules are (e.g, the index.js file doesn't apply here).

Milestone: https://github.com/golang/go/issues?q=milestone%3AGo1.15.5+label%3ACherryPickApproved

Release: https://golang.org/doc/devel/release.html#go1.15.minor

Announcement: https://groups.google.com/g/golang-nuts/c/c-ssaaS7RMI

Essentially the equivalent of the Alpine Linux images, but Debian-based in order to have glibc environment. This provides the necessary build/run environment for cgo-based Go applications that need use shared object/library files. In particular, I found that I needed this when testing a Go application that queries an Oracle Database server via the Oracle Instant Client.

Overview

After a lot more digging than I really set out to do, I learned that to build cgo-enabled projects for multiple platforms you have to either build on each of those platforms or either "cross-compile". Go makes this easy enough when building native code, but cross-compiling cgo-enabled code requires a toolchain intended for that purpose.

To build cgo-enabled applications for Windows, this appears to require installation of the mingw-w64 packages.

• not available any longer via CentOS 7 (EPEL)
• available in Ubuntu as the gcc-mingw-w64 package
• available in Alpine Linux as mingw-w64-gcc

Windows binaries can be built by setting one of:

• CC=i686-w64-mingw32-gcc
  • 32-bit
• CC=x86_64-w64-mingw32-gcc
  • 64-bit

Building cgo-enabled projects

Windows

With the packages installed, you can build a Go project that uses the cgo mattn/sqlite3 package like so:

GOOS=windows GOARCH=386 CC=i686-w64-mingw32-gcc CGO_ENABLED=1 go build -mod=vendor -tags 'osusergo,netgo,sqlite_omit_load_extension' -a -ldflags "-s -w" -o myapp-windows-386.exe ./cmd/myapp

or broken across several lines for readability:

GOOS=windows \
GOARCH=386 \
CC=i686-w64-mingw32-gcc \
CGO_ENABLED=1 \
go build -mod=vendor \
    -tags 'osusergo,netgo,sqlite_omit_load_extension' \
    -a \
    -ldflags "-s -w" \
    -o myapp-windows-386.exe \
    ./cmd/myapp

This produces an executable that can be run on x86 or x64 Windows.

Linux

This produces a Linux binary that be executed on 32-bit Linux:

GOOS=linux \
GOARCH=amd64 \
CGO_ENABLED=1 \
go build -mod=vendor \
    -tags 'osusergo,netgo,sqlite_omit_load_extension' \
    -a \
    -ldflags "-s -w" \
    -o myapp-linux-386 \
    ./cmd/myapp

It is however a dynamic executable:

myapp-linux-386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-i386.so.1, Go BuildID=lVPFRAyenbEQLUmnpGA_/RChqGeDql7ttjx1bS1nu/X6xTvLP6Goo_ybCQgWqm/WTrWxNJ-HEFz3gnIB5fV, stripped

If generated in an Ubuntu environment, the results are very similar, except the binary is dynamically linked against glibc:

myapp-linux-386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6558e540df4278b6256e87478e639129f10d7ce3, stripped

To generate a static executable, you need to use this set of options instead:

GOOS=linux \
GOARCH=amd64 \
CGO_ENABLED=1 \
go build -mod=vendor \
    -tags 'osusergo,netgo,sqlite_omit_load_extension' \
    -a \
    -ldflags "-extldflags '-static' -s -w" \
    -o myapp-linux-386 \
    ./cmd/myapp

Results:

myapp-linux-386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, Go BuildID=QccpDvCfaf8ddhENgPpL/RChqGeDql7ttjx1bS1nu/X6xTvLP6Goo_ybCQgWqm/e-zeBYsBO3_pB2ZRANeZ, stripped

libc licensing

I'm still trying to get a solid answer, but it appears that statically linking to the glibc library requires you to follow some very specific steps in the license which includes bundling a copy of the license, potentially hosting the source code in your repo, adding copyright information in your output and so on. None of it appears to be insurmountable, but there may be other requirements or repercussions that I'm not thinking of.

The musl libc project on the other hand is MIT licensed and does not appear to have the same restrictions in its usage.

Because of this, providing an image to build cross-compiled cgo-enabled static binaries could be very useful. If nothing else I would like to begin testing binaries generated with that c library.

This issue is intended to track the creation of a new set of x86 and x64 images for that purpose.

The plan is to pull in the golang:<version>-alpine images from https://hub.docker.com/_/golang so that we're not reinventing the wheel, and just add in the necessary packages to cross-compile both Linux and Windows binaries.

Hi gophers,

We have just released Go 1.14.7 and Go 1.13.15 to address a recently reported security issue. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.14.7).
encoding/binary: ReadUvarint and ReadVarint can read an unlimited number of bytes from invalid inputs
Certain invalid inputs to ReadUvarint or ReadVarint could cause those functions to read an unlimited number of bytes from the ByteReader argument before returning an error. This could lead to processing more input than expected when the caller is reading directly from a network and depends on ReadUvarint and ReadVarint only consuming a small, bounded number of bytes, even from invalid inputs.

With the update, ReadUvarint and ReadVarint now always return after consuming a bounded number of bytes (specifically, MaxVarintLen64, which is 10). The result being returned has not changed; the functions merely detect and return some errors without reading as much input.

Thanks to Diederik Loerakker, Jonny Rhea, Raúl Kripalani, and Preston Van Loon for reporting this issue.

This issue is CVE-2020-16845 and Go issue golang.org/issue/40618.

The upcoming Go 1.15rc2 release will also include the fix above.

Downloads are available at https://golang.org/dl for all supported platforms.

Thank you,
Katie and Filippo on behalf of the Go team

refs https://groups.google.com/forum/#!topic/golang-announce/NyPIaucMgXo

https://github.com/jondot/goweight

This could be useful output to review later, provided that it is kept for any useful amount of time.

Hello gophers,

We have just released Go versions 1.15.6 and 1.14.13, minor point releases.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.15.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.15.6" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Carlos and Dmitri for the Go team

I can borrow the workflow from one of my other projects.

https://github.com/kisielk/errcheck

Note: golangci-lint bundles this package and makes the functionality available via a flag option, so it might not be worth implementing this separately long-term. It may be worth enabling at least initially in order to compare the results.

refs:

• atc0005/send2teams#13
• atc0005/bridge#47
• atc0005/check-mail#19
• atc0005/elbow#218

See also:

• https://github.com/Djarvur/go-err113
• https://twitter.com/_mfridman/status/1293927689112424450

Not sure yet, but I'm thinking that I'll want to add this first to the unstable container image, then transition to the stable variants at a later point. Not sure yet how to track that aside from cloning an issue?

Perhaps create a Project board or board-item for new linters/linting config changes?

Will have to give this some thought.

https://github.com/securego/gosec

Bundled with golangci-lint, so we already have access to this linter. I'm not sure of the lag time between upstream release and incorporation into golangci-lint.

From the go-ci-unstable Docker images section:

• built from the latest available non-stable golang:rc image or if not
  recently available, the latest stable golang image
• used for building Go applications, both directly and via Makefile builds.
• used to test new linters prior to inclusion in the stable and oldstable
  container variants

The first two items could use some additional details; I need to stress that the primary purpose of the container image is to build existing projects using the latest unstable upstream Go release. I'm not sure that I want to limit the inclusion of entirely new linters to just this one container image variant. Since the linter binaries are not run by default, including them should not destabilize the stable or oldstable variants.

What I likely meant was new or additional linters included within the golangci-lint application. Enabling additional linters provided by that binary would likely need some additional testing. If that is what I meant (the more I think about it, the more I think that's probably the case), then I need to make that explicit.

• https://medium.com/orijtech-developers/httperroryzer-static-analysis-pass-to-catch-missing-returns-after-http-error-for-go-351ead575274
• https://github.com/orijtech/httperroryzer

Time to rebuild container images to pull this version in.

See also PRs #35 and #36.

Can be used for the TOML-format config file that is often included with my projects.

The official project provides a Dockerfile that lists out the build steps needed.

• https://golang.org/doc/devel/release.html#go1.15.minor
• https://golang.org/doc/devel/release.html#go1.14.minor

https://github.com/fatih/errwrap

From the package description:

Go tool to wrap and fix errors with the new %w verb directive https://arslan.io

Example output from running the tool in a WSL environment against the branch I'm using to test changes for atc0005/elbow#161:

$ errwrap ./...
/mnt/t/github/elbow/config/config.go:219:16: call could wrap the error with error-wrapping directive %w
/mnt/t/github/elbow/config/config.go:224:16: call could wrap the error with error-wrapping directive %w
/mnt/t/github/elbow/config/config.go:239:16: call could wrap the error with error-wrapping directive %w
/mnt/t/github/elbow/config/config.go:333:15: call could wrap the error with error-wrapping directive %w
/mnt/t/github/elbow/logging/logging_unix.go:115:10: call could wrap the error with error-wrapping directive %w