You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because the CI does not build the dev container but instead uses one that has to be build manually, we cannot properly check changes to the Dockerfile.
I feel like the switch to the github actions really was a regression in many ways. With the gitlab runner we used to build the containers for each PR separately and were still faster than github.
Has anyone somehow tested changes to the dockerfiles without just pushing a new image to the registry and hoping for the best?
The text was updated successfully, but these errors were encountered:
Hi, @n-eiling, I am pretty new to this topic and have not yet made any changes to the dockerfiles. Do you already have some ideas to improve on testing the changes of the Dockerfile? E.g., can the dev container build be automated?
yes, but afaik it was removed because it took too long. The only solution I see is moving to self hosted runners.
Or define a workflow for Dockerfile changes that avoids this.
As @n-eiling mentioned, we already had this automated but building the container images in the ci takes forever since we only use free resources in GitHub. So currently, the docker build job is triggered manually in the actions menu.
Because the CI does not build the dev container but instead uses one that has to be build manually, we cannot properly check changes to the Dockerfile.
I feel like the switch to the github actions really was a regression in many ways. With the gitlab runner we used to build the containers for each PR separately and were still faster than github.
Has anyone somehow tested changes to the dockerfiles without just pushing a new image to the registry and hoping for the best?
The text was updated successfully, but these errors were encountered: