Docker container does not have webgrid in PATH

[Shane Hughes]

🐛 Bug description

When you docker run the core docker container it errors stating the following

docker run webgrid/core:v0.1.3-beta
Unable to find image 'webgrid/core:v0.1.3-beta' locally
v0.1.3-beta: Pulling from webgrid/core
2d27e6858d13: Pull complete 
Digest: sha256:2787f2be59c33fb3a2e3d260ab41dc6dd6481218c5e4b10b98986f6c7018a091
Status: Downloaded newer image for webgrid/core:v0.1.3-beta
docker: Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "webgrid": executable file not found in $PATH: unknown.
ERRO[0002] error waiting for container: context canceled

🦶 Reproduction steps

Steps to reproduce the behavior:

1. docker run webgrid/core:v0.1.3-beta
2. See console output

🎯 Expected behaviour

I assume its supposed to start running the webgrid cli (Granted it would need args to run the specific funciton but it still should find webgrid cli)

If I build the docker container using the make file it works fine using the locally built container.

Context

Version
I tried all official docker containers

I have also used the helm chart which has the same outcome

resource "helm_release" "webgrid" {
  depends_on = [kubernetes_namespace.selenium]
  name       = "webgrid"
  namespace  = kubernetes_namespace.selenium.metadata[0].name
  repository = "https://webgrid.dev/"
  chart      = "webgrid"
}

Where did the problem occur?
List the platform on which you encountered the issue.

• ☸️ Kubernetes
• 🐳 Docker

[Til Blechschmidt]

Hi there! I've encountered some issues with building the images recently and wasn't aware that the current release still contained the broken image. Could you please try webgrid/core:v0.2.0-beta once the CI has finished the build?

Out of curiosity, why are you trying to run the core image standalone (without the docker-compose file / K8s chart)?

[Shane Hughes]

I assume this is automated to dockerhub?

[Shane Hughes]

I edited the above comment I tried the helm chart, I ended up having to build my own containers to get the entry point to work.

[Til Blechschmidt]

Yes, it is. Every time a GitHub release is published, GitHub Actions automatically builds and pushes a fresh image to Docker Hub.

For development purposes, there are also debug-build images available from the GHCR (see here) which are mainly used for test-deployments by myself and the integration tests.

[Shane Hughes]

Also, you should be able to add a step to your GitHub action to deploy the container and status check the /status endpoint before it goes and pushes it out 👍

[Til Blechschmidt]

Background info: The broken image is not caused by the file not being in the PATH (although Docker tells you that for some reason). The binary is actually there and in the PATH but it is not executable due to some compilation issues*.

*I've recently switched to an ARM M1 MacBook and thus had to re-work the whole compilation toolchain.

[Til Blechschmidt]

Also, you should be able to add a step to your GitHub action to deploy the container and status check the /status endpoint before it goes and pushes it out 👍

I've actually started playing with that by deploying the grid in both Docker and K8s and throwing a basic selenium test against it (see PR #15). But checking the /status endpoints as well is a good idea too!

(However, due to ongoing efforts these tests are not actually ran against the release builds, only the debug builds ... bound to change soon whenever I've got time for that :D)

[Til Blechschmidt]

Discussion continued on Discord #support channel.

[Til Blechschmidt]

The root issue (released images contained invalid binaries due to compilation issues in the release pipeline) has been fixed.