-
-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/shfmt: official docker images #68
Comments
Usually people would build their own docker images with multiple tools, not just https://github.com/search?l=Dockerfile&q=shfmt&type=Code&utf8=%E2%9C%93 In that list, there are also some people making small images with just this tool. Why should I make an "official" image? How is that better than just an official binary? |
reping @mmlb |
I'm going to close this, as I don't see how an official docker image adds anything on top of an official static binary. |
hey @mvdan So sorry to not respond, I somehow disabled email notifications and wasn't checking them from github. Its cool if you don't want to implement this, my use case was to not have to manage my own docker image and update whenever you updated, nor to have to download the static binary on each ci run. Its kinda nice that shellcheck has docker images that track master. It would require more work than I would want to do if I wanted to replicate. I would need to wire up ifft or something else to watch github's rss feed of this repo and update my docker image. I'll probably just have my own image and update that with your releases/master from time to time. |
You should not always use For example, I might add more simplification rules like the one that converts If you're updating to a newer |
flip side is to break things quickly. I'm ok with having shfmt/shellcheck running master and pinning to a version if something breaks or I want some time to come into compliance. I'd rather have the default be run latest and greatest (ahem Arch Linux user here btw) without having to worry about it, until I do where I'd favor fixing the code. |
Sure, but I don't want to encourage that even when I'm an Arch user too ;) If we're talking about automation of Docker image building, why is it easier to do here than in a separate repo or place? Could you not watch for changes externally? |
Its kind of a pain to do so. Docker needs to install hooks into the repo to do the builds, but since its not my repo I don't have perms to do so. The other option (which I started to toy with for something similar) was to hook up ifft or zapier to watch an rss feed and then trigger docker hub. It would watch the rss feed for the master branch for example. Looked doable, but definitely more work (and would be duplicated if anyone else wanted this setup) than you providing. |
Okay then - happy to have it part of this repo as long as you tell me what to do and submit a PR with the Dockerfile. Also assuming this is about a docker image tracking master, and not tracking released versions. I don't know if you'd want these too, or if they could also be handled automagically. |
oh cool! Alright I'll work that out. I think both master and tagged release can be doable. |
Bump @mmlb - do you still plan on working on this? |
Hey mvdan, I do plan to do this just a bit swamped at work at the moment. I expect to have some time later in the week or early next. |
That's fine, there is no hurry - just wanted to make sure this wasn't a zombie issue :) |
hey @mvdan seems it turned into a zombie issue ;). Turns out the docker image is not quite as useful as I thought because of the way I'm using shfmt in ci:
So unless you'd be ok with adding git to the image then there's no benefit for me. Alternatively, having |
I think adding a diff algorithm would be overkill for the tool. Composable tools and all that :) It also raises the question as to where to stop. Do we also include something to replace I'm going to close this since, as you say, there's little benefit in an image as things are now. Thanks for your input! |
Ah, I also forgot to say - you can always use |
yeah I may try going with the |
Note, however, that |
oh I did not know that. I was thinking about using either |
Requiring the image to have |
Not quite, In the typical CI setup, source has already been fetched, and I think its better to have slim images instead of fat one ala travis. |
sorry, going back to advantages over providing an official binary, I see a docker image more like providing an official package. Which I believe you do. -- sincerely a non arch user 😱 |
@jamesmstone Thanks for your docker image jamesmstone/shfmt 👍 . |
Seems clear to me that users want this, so I'm fine with having an official image as long as it can be built and pushed automatically via https://docs.docker.com/docker-hub/builds/. Assuming that obtaining https://hub.docker.com/_/shfmt/ would be difficult, we can just go with https://hub.docker.com/r/mvdan/shfmt/ for now. @PeterDaveHello I'll take some ideas from your Dockerfile, since you seem to have the latest version, if that's ok. |
Here is my Docker image repository if anyone likes to try: peterdavehello/shfmt, which is built automatically on Docker Hub, and here is its GitHub repository: PeterDaveHello/dockerized-shfmt. @mvdan I'm also a maintainer of the official node image, so I'd like to help make an official shfmt image if it's possible, just need to tell you that the official repository is not using automatic build, it needs pull request and review everytime to have a new release, not sure this is 100% you want, I can also invite/add you as collaborator of my Docker repository if it's easier for you, what do you think? |
How easy is it to obtain an official repository?
I'm curious - why is that? I'd be fine with a bit of overhead per release, if that means it can be an "official" Docker repository. But I don't think it's a dealbreaker, as I think automatic builds from the upstream git repo to a docker hub repository owned by the author should be good enough.
Thanks for the offer! I think it will be best if we keep the Dockerfile somewhere in this repository, to tie it with the rest of the upstream code. Unless there's a reason to specifically put it in a separate repo? |
I haven't done that yet, I'm not the first maintainer of node's Docker image.
I don't have a certain answer, maybe it's just to make sure its quality.
To have an official Docker hub repository may need a separated one, as there are also some scripts and Dockerfile related files being developed and they are not directly related with the application development. If you don't mind, I can try to make my original repository to be the source repository of it. |
Ah, I've looked at the docker-node repository and I agree that the file and directory structure would not fit well in this repository.
Sure, feel free to give it a go. I'll probably publish |
Pinning versions of the builder and final base image, so that its behavior doesn't change over time. Updates #68.
I wanted to point out a few things about 3f0ab69 I'm very excited to see you're working towards having an official docker image! I noticed https://hub.docker.com/r/peterdavehello/shfmt/tags/ seems to also have v3 alpha which is cool, and would be cool to see in an official capacity. More importantly though, there is no Also to compare to @jamesmstone image I am able to run docker run --rm -v ${VALIDATIONPATH}:${VALIDATIONPATH} jamesmstone/shfmt ${VALIDATIONPATH}/file.sh Notice there is no tag (because latest is implied) and the image name seems to imply the use of the By contrast this is what I have working with your official image docker run --rm -v ${VALIDATIONPATH}:${VALIDATIONPATH} mvdan/shfmt:v2.6.1 shfmt ${VALIDATIONPATH}/file.sh Note that the version tag was required in this case, and then also the command had to be included. The command being required isn't a huge issue, but it would be nice if it were not required as this is similar to many other images for tools like this. Here is my specific usage for reference Thanks! |
v3's alpha0 was really just to kickstart the v3 Go module, it doesn't include anything else as a release. I'm not yet sure if I'll publish future alphas on Docker Hub, but I'd publish betas there for sure.
That was kind of on purpose. Seems to me like a "tag" that just follows the latest version isn't particularly useful in the long run. For example, once v3 is final, that might introduce breaking changes, meaning that I realise this is all "use at your own risk", but I don't want to encourage that kind of usage. I'd prefer doing something like a Another option would be to have
I was thinking about this for a while, actually. This repository can hold multiple binaries - for example, there's a Of course, the issue then is that I think the packaging of |
I would think if you wanted to run I would be all for the I still feel there's validity to versions being tagged, especially past versions, but also dev versions like v3 while it's in alpha. This gives people the ability to pin themselves to a specific build if they need or try future builds before they become |
I'll update the Dockerfile to add I'll also look at adding a |
Now the Dockerfile is version agnostic, so it can be used to build a master version as well as any tagged version. It also uses COPY instead of a git clone, so it's much faster and no longer requires an internet connection. These changes mean that we can no longer use Docker Hub's automated builds. Which is fine, because they were painfully slow anyway. While at it, add an ENTRYPOINT as suggested in #68.
Both fixed:
|
On second thought - I had forgotten that Travis secrets currently break their Windows builds. Testing on Windows is vastly more important than pushing |
So for the moment we can use |
You can use either |
My builds look good, thanks for the updates! |
@mvdan Hey! What do you think about having 2 images, similarly to The reason for this request is that some CI tools (for me it's GitLab Runner) require the Docker images to have a shell installed in order to execute the |
That's a bit of a niche requirement :) I guess I'm fine with it as long as it's automated. I'll take a look once v3 is released and once I've moved off of Travis. |
@vittorius meanwhile you could use something like this: shellfmt:
image: docker:stable
services:
- docker:dind
script:
- docker run mvdan/shfmt:v2.6.4 --version
- docker run -v $(pwd)/psu:/psu mvdan/shfmt:v2.6.4 -i 2 -ci -l psu This DIND approach only works in CI products where you can actually use DIND. For example, it works in GitLab CI and Circle CI, but not in Drone CI. Having an official image with a shell, as you propose, would be more efficient and more portable. |
Now that v3.0.0 is out, we're back with proper release and master images. Each tagged version is the same as the git tag here, and @vittorius the current image is based on busybox, which should contain a POSIX shell. I've just verified that with |
For what it's worth, once v3.0.2 is out, the |
I'd be great if you could provide a docker image on docker hub. My use case is to use it with drone.io, there are other CIs that can use docker images natively. Something like:
would work for me.
And maybe the following for automated builds:
The text was updated successfully, but these errors were encountered: