streamlined rebuild when base image of "latest" changes

pkim-auro @pkim-auro 16:57 greetings again - ran into a behavior that was interesting. finally refactored one of my projects to use forge. It uses a custom base image. I made changes to the base image project and built it locally. First run was fine since it was a new build and it used the local latest. I made some more changes to base image, rebuilt it but forge did not rebuild the image because it was "latest". I got around it by adding some dummy tags on the base image and then changed the forge dockerfile. Is there any tricks here in order to force use the "latest" "no cache" "local" version of the base image (FROM syntax in dockerfile)?

Rafael Schloming @rhs 17:05 @pkim-auro not really... I can imagine adding a -f or something, but the behavior you are seeing is the result of forge trying to ensure that builds are idempotent basically for a git set of input sources (as determined by an automatically computed version hash of all the input source) forge will never overwrite the docker image produced by that input we generally avoid latest, so it's not really a problem in our workflow

pkim-auro @pkim-auro 17:08 but git isn't quite involved here since i have the base image locally available i suppose git / dockerhub

pkim-auro @pkim-auro 17:13 so if i need to make a change to base image, we have to modify the forge enabled Dockerfile to whatever temporary tag to force it to use the right build. build deploy test, but when we have to commit, I would revert the dockerfile back to the latest to keep in line with all the other projects who are using latest. We're honestly kinda split on if custom base images should be latest or be versioned per project =)

Rafael Schloming @rhs 17:15 I'm pretty sure I could provide a streamlined option for that. I can't think of a way that forge can magically know that latest changed underneath it (although if there is a way to know I can probably make that work too).

pkim-auro @pkim-auro 17:16 we ran into a similar issue in jenkins and dockerhub where because of an auth issue , it wouldn't pull down latest, but it found a previously existing latest locally. since our jenkins was/is in kubernetes, that latest could have been a few days ago if it was on a different not. We ended up fixing it by fixing the auth issue to make sure it always pulled down latest form the hub the docker digest is the way i know

Rafael Schloming @rhs 17:16 But I can probably provide an option that you could pass in that says "hey, I know this changed so ignore the cash" or something.

pkim-auro @pkim-auro 17:16 lol or that

Rafael Schloming @rhs 17:17 Personally I'm biased towards never using latest because I've confused myself too many times with it. :wink:

pkim-auro @pkim-auro 17:17 haah me too but there's only so much i can enforce FYI your option to "hey, I know this changed so ignore the cash" has an equivalence in Jenkinsfiles - let me dig it up

datawire / forge

streamlined rebuild when base image of "latest" changes #169