drud / build-tools Goto Github PK

It's easy to see from the commit log what build-tools is installed, but it would be much better if it just self-documented its version when installing.

This needs to be confirmed, but I took a quick spin with the new golang "dep" tool, and it expected to use .go (as a file, I think), but we have it as a directory. IMO we should move out of the way soon, maybe .build or something.

What happened (or feature request):

Docker toolbox is no longer useful and is deprecated in ddev.
Remove testing here.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

What happened (or feature request):

Feature request: Currently $(VERSION) uses just the git committish (based on tag) for its name. @beeradb points out that it might be nice to have the branch name in there as the former 'canary' target did. Might be nice to have username as well? Tag could get unwieldy, but it might be worth it.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

What happened (or feature request):

Our preprocessing approach to providing the upstream docker build is no longer necessary, as Docker provides replaceable FROM now. See moby/moby#31352 and https://www.jeffgeerling.com/blog/2017/use-arg-dockerfile-dynamic-image-specification

We should probably deprecate that approach and move handling into the Dockerfile (or Dockerfile.in). A fair bit of effort went into the Dockerfile processing for this exact feature, so it's slightly painful to work our way back out of it. But I really don't like having the FROM in the Makefile anyway, so maybe we can battle out, especially in the docker.nginx-php-fpm family of containers.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

What happened (or feature request):

I note that "make clean" in the container build is not fully reliable because although it removes other artifacts, it does not remove docker images that might be related to the build. make clean should remove all docker images for the current $VERSION.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

What happened (or feature request):

build-tools currently fail all builds if you use the minikube docker environment. Moving forward, it's pretty important we be able to build our binaries/containers using the minikube instance of docker, to prevent having to continually push images for a dev workflow.

To reproduce:

Assuming you have a minikube instance running, on any project using build tools and building a golang binary run the following:

eval $(minikube docker-env)
make darwin

You'll receive the following error:

drud/site-manager ‹minikube› git:(master) » make linux
building linux from ./cmd/...
go install runtime/internal/sys: mkdir /usr/local/go/pkg/linux_amd64_static/runtime: permission denied
make: *** [linux] Error 1

What happened (or feature request):

Over in https://github.com/drud/docker.nginx-php-fpm/pull/39#pullrequestreview-33582227 it was noted that the suggested bin/ rule in gitignore.example has unintended effects. It should probably be improved to not do that.

All of the other unrooted examples (.go, etc) could have the same problem.

What you expected to happen:

gitignore should not have unanticipated results.

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

What happened (or feature request):

The preprocessing of the Dockerfile into .dockerfile is long-since obsolete and unused. Remove it. This has been obsoleted by Docker's ability to do multi-stage builds.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues (like source JIRA issue):