Improve container rebuild performance, features installation order and pinning version #327
Replies: 1 comment
-
Hey there! To your comment on installation order, there's been a fair bit of discussion on this in past discussion (if you're curious on the historical reasoning #43, #109). There's three ways to influence installation order (see https://github.com/devcontainers/spec/blob/main/docs/specs/devcontainer-features.md#installation-order). Note that with Thanks for flagging the codelens issue and for the feedback - looks like a string sorting issue that i'll take a look at! |
Beta Was this translation helpful? Give feedback.
-
the problem I've in hand is, devcontainer build takes a long time, Codespaces prebuild is not the solution I'm looking for.
rebuilding is something very common, as I try to modularize configurations as features frequently. the
features
entry indevcontainers.json
is an object, so there's not an explicit agreement of the order, and based oninstallsAfter
config in each feature. That means the new feature added may not be the last feature in that order - and break the container build cache of many features needlessly.one solution would be to
overrideFeatureInstallOrder
, but that becomes too tedious and error prone. I think it'd be more ideal iffeatures
was an array, that hints the preferred order, and then dictated byinstallsAfter
. I don't think it's a new idea, as it's kinda obvious one to me. hope someone can point me to relevant discussion on this, or if I'm wrong in my assumptions.another thing that would be nice, to have a button (alongside the
update to latest
button) that sets feature version to patch release. for example, if the version is set tosome-feature:1
convert that tosome-feature:1.0.2
.btw I think there's a problem here - the suggested version is lower than what already is set!
I know this repo is for only the spec, and some portion of what I've said is not directly related to the spec.
Beta Was this translation helpful? Give feedback.
All reactions