https://github.com/mvdan/dockexec

Run Go tests inside a Docker image
https://github.com/mvdan/dockexec

docker golang testing

Last synced: 11 days ago
JSON representation

Run Go tests inside a Docker image

• Host: GitHub
• URL: https://github.com/mvdan/dockexec
• Owner: mvdan
• License: bsd-3-clause
• Created: 2019-12-02T16:13:05.000Z (almost 5 years ago)
• Default Branch: master
• Last Pushed: 2023-08-15T10:23:02.000Z (about 1 year ago)
• Last Synced: 2024-10-14T11:55:19.779Z (24 days ago)
• Topics: docker, golang, testing
• Language: Go
• Size: 52.7 KB
• Stars: 98
• Watchers: 5
• Forks: 5
• Open Issues: 2
• Metadata Files:
  • Readme: README.md
  • Funding: .github/FUNDING.yml
  • License: LICENSE

Awesome Lists containing this project

README

        
# dockexec

Run Go tests inside a Docker image.

	go install mvdan.cc/dockexec@latest

	go test -exec='dockexec postgres:12.1'

You can also use custom flags for `docker run`, as well as any test flags:

	go test -exec='dockexec [docker flags] image:tag' [test flags]

`go run` is also supported:

	go run -exec='dockexec postgres:12.1' .

The goal is to easily test many packages with specific Docker images, without

having to write the boilerplate code yourself. All previous alternatives weren't

any good:

* Running `go test` inside `docker run` requires your Go version to be installed

  in the image.

* Running `go test -c` and running the test binary under `docker run` is

  tedious, error-prone, and doesn't scale to many packages.

### Caveats

* `go test` without package arguments runs tests with access to the current

  terminal. However, `go test -exec="dockexec $image"` will not, as `dockexec`

  cannot distinguish this mode from others like `go test -exec="dockexec $image"

  ./...`. If you want access to the terminal, supply the `-t` docker flag.

* Docker images are assumed to be unix-like at the moment, and only Linux images

  are tested. Other platforms like Windows-native images may be supported in the

  future.

* Beware that the Docker image may not have compatible C libraries, given the

  default of `CGO_ENABLED=1`. If you run into "no such file" exec errors,

  or glibc version mismatch errors, you should consider disabling cgo via

  `CGO_ENABLED=0` or a [fully static build](https://github.com/golang/go/issues/26492).