You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once I've done all of that I get the best of both worlds.
Anytime I want to float to the latest version bounded by all of my dependency version ranges I run ./gradlew dependencies --write-locks.
It is my desire to have a similar capability with jib base image declarations.
Whenever I run some command like -write-locks the sha of the latest version of my base image is discovered and then written to some kind of like file. That sha is then used until such time as I run --write-locks again.
Of course all of this can be done manually. I've just gotten so used to the convenience afforded by the combination of gradle's version range declarations and its lockfile capability.
The text was updated successfully, but these errors were encountered:
Gradle has dependency version lockfiles
I can declare my dependency versions as
latest.release
or[3,4[
(any version 3.x, but nor 4.x).This offers flexibility at the cost of build reproducibility.
I can restore reproducibility by turning on dependency locking.
Once I've done all of that I get the best of both worlds.
Anytime I want to float to the latest version bounded by all of my dependency version ranges I run
./gradlew dependencies --write-locks
.It is my desire to have a similar capability with jib base image declarations.
Whenever I run some command like -write-locks the sha of the latest version of my base image is discovered and then written to some kind of like file. That sha is then used until such time as I run --write-locks again.
Of course all of this can be done manually. I've just gotten so used to the convenience afforded by the combination of gradle's version range declarations and its lockfile capability.
The text was updated successfully, but these errors were encountered: