-
Notifications
You must be signed in to change notification settings - Fork 18
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
Rewrite without lockfiles #65
Comments
The way that I use the tool is: Currently, if you specify your digest in your Dockerfile, the tool assumes that you want to keep that digest hardcoded, and it does not look up a new digest from the registry when running If I understand correctly, you are asking basically for: These sound like good features to me. Just curious, any particular reason why you would prefer to leave the digests in the Dockerfiles rather than use a Lockfile? |
You're understanding it exactly right. We don't have a particularly strong preference for this, we just don't see enough value in keeping this data in a separate file. Plus we want to make sure our Dockerfiles are always ready to build - keeping the digests separately might cause a drift if we're not careful. While we do use digests for other runtimes (Python, most often), the difference there is that we can install from lockfiles directly, but since |
The point about drift is a good one, and I can see why someone would prefer to not use a separate file. I imagine the features would look something like: (1) In terms of priority, I am in the process of refactoring so that the code is more generic/reusable (currently parts of the code base are too heavily tied to the type of file i.e. Dockerfile, Composefile, Kubernetesfile) as there are a variety of other types of files I want to support such as github actions yml. I would have bandwidth to work on these 2 features after this refactoring is done, which I imagine would start in 2-3 weeks. Otherwise, if you have interest in trying your hand at either of these features or have any suggestions, please feel welcome and I will backport them once I have finished refactoring. Thanks! |
Cool cool cool. I'm in no rush, we're still evaluating what our options are and we can replicate our desired workflow even with lock files, so it's not a blocker. Also, I think this feature is not so much about writing code but about the UX of the workflow, so I'd rather take the time and test out various options before settling on something. What's more pressing is ECR support - |
Sounds great, thanks for the background. ECR support is definitely easy to add -- I personally use ACR and left that as an open task since I do not have an AWS account (and didn't look into seeing if free ones exist, so tests could run in the CI). Since all the registries implement the same API, it would be easy to add ECR, and I am happy to do so next week. If there are free accounts, I will make sure it runs in the CI as well. |
@kokes PR #71 and release v0.7.3 allows you to now say:
which will record the new digests in the Lockfile, even if they are hardcoded in your Dockerfiles. So for your usecase, where you don't care about the lockfile, you can say:
And your digests will always be tracked in the Dockerfiles. As to being able to do this in one line, I think it is a good idea, but I am going to focus on a few other issues first. |
@michaelperel Cool, this works as expected. I only ran into one weird edge case. Not sure if that's a good practice, but some of my Docker FROM clauses look like this (no tag, digest included; it builds):
And these are completely ignored by docker-lock, or at least by Note that if I delete the digest altogether, docker-lock will add the tag |
@kokes Currently This is because multiple tags can have the same digest. For instance, currently I figured keeping the digest the same as written in Dockerfile made the most sense. Perhaps in these scenarios, a warning log message should be printed? To the last point, |
Additionally, if you pull an image by the digest for an image you do not have locally, such as: and then run you will see that the tag is So I am not sure if it would make sense to update an image with a tag of |
@michaelperel makes sense. I guess a log message about a given image being ignored due to the lack of tags would be useful. This way it just silently ignores it, which I found a bit too... silent. |
@kokes the log statement is in the most recent release, v0.8.3 |
The way we'd like to use a tool like docker lock is that we'd leave the digests in our Dockerfiles and upon each rewrite, we'd lookup the current digests and replace the outdated ones. We don't have a particularly good use of the lock file.
So we'd essentially do
docker lock generate && docker lock rewrite && rm docker-lock.json
- are we alone in this? If not, wouldn't something likedocker lock rewrite --no-lock-file
or something along those lines be of use? It'd do thegenerate
step (in memory) and rewrite the Dockerfile without saving these into a lock file.This is just a tentative proposal, maybe we're misunderstanding the intended workflow.
The text was updated successfully, but these errors were encountered: