-
Notifications
You must be signed in to change notification settings - Fork 0
chore: remove unneeded versions #8
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
base: main
Are you sure you want to change the base?
Conversation
Also makes a minor modification to the logging on the Makefile and the use of env vars for more control on what is built.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether we should un-pin packages that live outside of this repository, this counts for vscodium too. Also should the versions in the frontends buildpack get un-pinned too ?
@@ -2,39 +2,35 @@ description = "Ubuntu 22.04 Jammy Jellyfish full image with buildpacks for Apach | |||
|
|||
[[buildpacks]] | |||
uri = "docker://ghcr.io/swissdatasciencecenter/vscodium-buildpack/vscodium:0.2" | |||
version = "0.2.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should un-pin buildpacks that do not live in this repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the tag for all of them is already in the uri. So why have the tag in two places?
|
||
[[buildpacks]] | ||
uri = "docker://gcr.io/paketo-buildpacks/go:4.13.11" | ||
version = "4.13.11" | ||
id = "paketo-buildpacks/go" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the tag is already in the uri. So why have the tag in two places?
|
||
[[buildpacks]] | ||
uri = "docker://gcr.io/paketo-buildpacks/nodejs:7.4.0" | ||
version = "7.4.0" | ||
id = "paketo-buildpacks/nodejs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tag is in the uri
|
||
[[buildpacks]] | ||
uri = "docker://gcr.io/paketo-buildpacks/python:2.24.3" | ||
version = "2.24.3" | ||
id = "paketo-buildpacks/python" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tag is in the uri
[[order.group]] | ||
id = "paketo-buildpacks/go" | ||
version = "4.13.11" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have this though:
[[buildpacks]]
uri = "docker://gcr.io/paketo-buildpacks/go:4.13.11"
id = "paketo-buildpacks/go"
[[buildpacks]]
uri = "docker://gcr.io/paketo-buildpacks/nodejs:7.4.0"
id = "paketo-buildpacks/nodejs"
[[buildpacks]]
uri = "docker://gcr.io/paketo-buildpacks/python:2.24.3"
id = "paketo-buildpacks/python"
[[extensions]]
id = "renku/renku"
uri = "../../extensions/renku"
[lifecycle]
version = "0.20.6"
[[order]]
[[order.group]]
id = "renku/frontends"
[[order.group]]
id = "paketo-buildpacks/go"
[[order.group]]
id = "renku/kernel-installer"
optional = true
So the tag of the buildpack is already specified in the buildpacks section. In the order we just use the id to refer to that same buildpack. So the versions in the builder are not needed.
[[order.group]] | ||
id = "paketo-buildpacks/python" | ||
version = "2.24.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and there
[[order.group]] | ||
id = "paketo-buildpacks/nodejs" | ||
version = "7.4.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and here
Thanks for your remark. It prompted me to check whether there is an actual reason for the version numbers in the spec. I learned something in the process. It is used for cache invalidation at build time and for layer re-use |
@SalimKayal do you think then it is better if we have stuff like this?
Because in this case at least it is not repeated twice. |
Good, question, does it pull the correct image ? |
Also makes a minor modification to the logging on the Makefile and the use of env vars for more control on what is built.