Make docker build produce a runnable wait-for image. #2
Conversation
Adapted from [gesellix's PR](eficode#2)
f6c9622 to
e5b0de6
Compare
|
This is now rebased on top of the recent changes. |
:) I have to admit that the update was a bit rough. After your review I had a deeper look and it seems like some other issues have to be fixed. I'm going to update the pull request so you can review again. |
7c7810a to
6b13906
Compare
.gitattributes
Outdated
| @@ -0,0 +1 @@ | |||
| wait-for text eol=lf | |||
There was a problem hiding this comment.
Do we need this? I haven't had issues so far with line-endings nor heard anyone else about it.
If we need it, can we then set it for the entire repo? It would be the preferred line-ending for all files anyway, nothing specific to the wait-for script.
| wait-for text eol=lf | |
| * text=auto | |
https://www.git-scm.com/docs/gitattributes#_end_of_line_conversion
There was a problem hiding this comment.
I'm sometimes working on Windows and I didn't configure my eol conversion globally. The local working copy failed to work in combination with the Docker container based tests. I'm going to move this change to a dedicated issue and we can continue the discussion over there.
865d3f4 to
4bce480
Compare
4bce480 to
f52ab7c
Compare
|
Sorry for the forced pushes - I hope they won't confuse you too much. I felt that the commits had been too confusing after the reverts for #100 and the .gitattributes. |
|
#100 is in |
… layer during docker build)
f52ab7c to
801d014
Compare
|
@Addono I think this is complete now. You're probably going to merge with a squash commit? I'm asking, because I only now read about the contributing guidelines in the Readme and that conventional commit messages are required 😅 If you prefer to keep each commit, I can certainly update the commit messages. |
|
I added another commit 801d014 to reflect the Dockerfile changes in the Readme. |
Yeah, I was planning on squashing it anyway. That's one reason why I wanted to take the unrelated changes in a separate commit :) |
|
Thanks @gesellix, here we are over 5 years later 😅 . But finally it landed 😄 . For now, I merged it in as a non-release triggering commit, because I would like to keep our semantic-versioning to target the main script itself. |
|
Yeah, 5 years later and still relevant. So thanks for maintaining the script and many thanks for the constructive feedback in this pull request! :) Next up: an official Docker Image at the Docker Hub. Do you think this might become available in, say, 5 years? 😬 🤪 😉 |
🤭 Hopefully 🤞 Pushing the container to a registry is technically not that hard, but at least for Docker Hub I need to get access to the Eficode organization, which is a bit "dusty". After that it's less than an hour work. Otherwise, GitHub Packages could also be an option 🤷 . |
🌁 ;) I'm unsure if GitHub Packages would be convenient from the users' perspective. AFAIK GitHub requires authentication, while Docker Hub works without authentication (most of the time). That said: GitHub Packages are a step forward!👍 |
|
Yeah, I know. Tripped me up the first time trying to use a GH-hosted container image too. Although nowadays "on my local machine it just works", which means there's no problem with that road anyway, right? 😉 Pushing to both wouldn't be hard either. Automate once, run forever 😄 |
|
And we're live! 🚀 It's auto-building latest from For now, I recommend pinning your version using SHAs. Later the tags should be immutable - don't think we will enforce it but the automation won't build new images for old tags, so effectively it should be. One thing which is still todo is adding documentation on this new way to use the container. Another day though. |
|
That's great, thanks a lot! |
|
Only as a thought, I'm unsure if this is an issue: the image at eficore/wait-for is built for linux/amd64, which might be an issue on Apple M1 (linux/arm64). I have to check if a multi-platform image is necessary, but I guess it won't. edit: works flawlessly on Apple M1 :) |
Good 😄 , because Docker Hub's own auto-build infra doesn't seem to support it 😇 |
This change adds a multi-stage build so that the resulting Docker image is a suitable base for a runtime container. It would be nice if you could add an automated build on the Docker Hub.