Update node.js default ubi image #64
Conversation
|
I'm guessing this may need to wait until redhat-developer/odo#4303 is resolved? |
|
Would someone with permissions be able to rerun CI, please? As discussed elsewhere, the test failures do not appear to be from the Node.js DevFile |
|
LGTM I rerun the test and it is passing now. The version number increment is up to the stack. In general, we recommend SemVer.
I haven't merged this one yet based on this comment. |
| @@ -12,7 +12,7 @@ starterProjects: | |||
| components: | |||
| - name: runtime | |||
| container: | |||
| image: registry.access.redhat.com/ubi8/nodejs-12:1-45 | |||
| image: registry.access.redhat.com/ubi8/nodejs-14:latest | |||
There was a problem hiding this comment.
@elsony, are there any rules around container versions for stacks - is it advised that we opt for a fixed version or is it okay to pull from a latest tag?
There was a problem hiding this comment.
It's entirely up to the stack. When you are deciding whether you want to pull in a static version vs latest, you may want to consider the update strategy of your stack. If you are pulling in the latest, the benefit is any non-breaking changes that was introduced to the image will be automatically picked up by the user who has created the stack before. On the other hand, in case breaking changes are introduced to the image (e.g. requires reacting changes to the commands in the devfile to work with it), it may potentially break existing user applications. The existing applications that were created before will refer to the latest image but they don't have the required changes on the commands on their existing devfile.
Another approach that you can consider is to introduce something like a 1.x stable image where you can still update for bug fixes/compatible changes. It will still leave room to allow you to create a 2.x stable image in case you need to introduce breaking changes to the image in the future without breaking existing applications.
There was a problem hiding this comment.
I would be a +1 for using latest in this case. node 14 is LTS, so there shouldn't be any breaking changes at this point. Also using latest makes it a little easier to deal with any CVE updates.
For future node releases like Node 16, we wouldn't send a PR to update the devfile until it is LTS anyway, so we wouldn't worry about breaking changes.
thoughts?
There was a problem hiding this comment.
Agreed. I think latest is okay here as we're very unlikely to pull in any changes that will require reacting changes in the DevFile. latest should also make maintenance a little easier for us.
|
@elsony I think odo CI will be fine with this change because we're mostly storing the devfiles and example repos' source locally on the odo repo to avoid pulling from GitHub numerous times.
That issue and its related PRs are about adding |
I'm a little confused by this comment, as this PR is updating the DevFile to default to |
Ah, my bad. I'm not sure why my brain read it as |
That PR is completely unrelated to this. redhat-developer/odo#4070 affects only s2i builder images, it has nothing to do with Devfiles |
Recently the Red Hat Software Collections released the node.js-14 UBI image (since this is an LTS version, should be fine to use it as the default image on devfiles).
Since we don't know how you guys bump devfiles versions we left that unchanged (v1.0.0). If I also have to bump the version in this PR please let me know.