It appears that after the large refactor of docker-go-dev, some dependencies that workflow-e2e relies on is missing, preventing workflow-e2e from upgrading to 0.20.0.

See deis/workflow-e2e#336 for log output.

The readme should be updated to ensure a more accurate description of image contents since new tools have been added recently.

Golangci-lint is a faster version of gometalinter and provides more features as well.

https://github.com/golangci/golangci-lint#performance

Remove archived/deprecated projects, such as:

• dep
• glide
• gb
• gometalinter
• go-bindata
• Helm v2 (replace with v3?)
• golint (not deprecated but is it still needed with golangci-lint?)
  anything else?

@mboersma what do you think?

Due to removal of python3-pip
tag: v1.26.2

Wonder if anyone else is having similar issues. @tariq1890 has a change in Azure/acs-engine here that statically pins a go-bindata version to a particular repo to avoid downstream changes conflicting:

Azure/acs-engine#3527

Basically, should we remove the go get convenience from this image and require each use case deliver their own, opinionated (and specific) version?

Thoughts?

Some users have used doc( instead of docs( in their commits. We should also throw those into the changelog, or alternatively enforce a new script across all repos to enforce the commit guidelines (not recommended).

related: deis/deisrel#21

(Chore)

Probably one for once it comes out of preview but v10 includes a bunch of performance upgrades, sync'ing and jobs amongst other features. Something to keep an eye on.

https://github.com/Azure/azure-storage-azcopy

All other versions of deploy.sh are standardized on QUAY_USERNAME and DOCKER_USERNAME, so this script should be updated.

See also deis/docker-python-dev#8.

Many Thanks!
@mboersma

Its missing some dependencies needed by helm/helm#418

Hey @mboersma, any reason why this is still calling derekparker/delve?

It is 168 commits behind official https://github.com/go-delve/delve

dlv enables step by step debugging in vscode targetting a container through remote debugging.
see https://github.com/Microsoft/vscode-go/wiki/Debugging-Go-code-using-VS-Code

It's just confusing to have the repo deis/docker-go-dev produce the docker image quay.io/deis/go-dev, and I would argue prepending "docker" is either redundant or packaging-specific.

Please be aware travis-ci.org will be shutting down in several weeks, with all accounts migrating to travis-ci.com. Please stay tuned here for more information.

Might need to migrate PRs from Travis

I'll grant that the need for this isn't immediately obvious, but I think I can cite some defensible reasons for it...

I've been investigating how best to enable functional and integration tests for the router. These really cannot be accomplished without a k8s cluster to test against, so I have also investigated what it would take to run a containerized k8s cluster. It's not that hard to do, but there are certain difficulties one encounters. See deis/router#140 for some discussion of that. One such difficulty is that the k8s apiserver only binds to localhost:8080 on the docker host (not 0.0.0.0:8080). This can be problematic for anyone using docker-machine as their docker host is essentially remote and their kubectl client would be unable to talk to the apiserver.

By including the kubectl binary in the containerized development environment, any test targets or other processes that must manipulate the containerized k8s test cluster could also be containerized, and in the case of anyone running docker-machine, this moves these processes to the "remote" docker host where the fact that the apiserver is bound to localhost:8080 is no longer a problem because it's accessible.

Including kubectl in the dev environment isn't any kind of magic bullet, but it's a good step toward making these sort of tests more feasible at the component level.

I'm interested to know what others think about possibly including kubectl.

Tagged builds in master all have been ending with:

Skipping a deployment with the script provider because this branch is not permitted

Does there need to be an on: master line in the deploy stanza to whitelist this branch explicitly? I couldn't tell from the Travis docs.

(I published quay.io/deis/go-dev:0.11.0 old-school, so this issue isn't blocking anything currently.)

Similar to what builder does in its .travis.yml file, docker-go-dev should run make ... docker-build to ensure that the Dockerfile is correct

:)

See deis/workflow#369

OS: MacOS 11.4
Docker: 20.10.7

build binary:

git clone [email protected]:Azure/aks-engine.git
cd aks-engine
docker run --rm \
-v $(pwd):/go/src/github.com/Azure/aks-engine \
-w /go/src/github.com/Azure/aks-engine \
mcr.microsoft.com/oss/azcu/go-dev:v1.32.2 make dist

run binary:

./_dist/aks-engine-nightly-darwin-amd64/aks-engine
zsh: killed     ./_dist/aks-engine-nightly-darwin-amd64/aks-engine

if remove upx compresstion in Makefile - it's will be ok - if update upx to latest v3.96 it's also will be ok

Azure/aks-engine#4513