Agents: pull all default defined images on start / or new release ?

[6543]

so we wont need that https://floss.social/@WoodpeckerCI/109595047113683395 in the future

[anbraten]

We please should use fixed tagging of such images instead as discussed earlier.

[6543]

it we also pin the patch version ... we would have to release a new woodpecker version just to bump a bugfix ...

pining majour and minor still is usefull as that way we make sure it will exactly as intended with no features/enhancements or even breaking changes added

[gapodo]

I have a question and a thought on this topic...

What is concidered a default defined image? just the git-plugin, all images in the default escalate list,...?

"Forced pulling" is IMHO generally a bad idea...

• you may introduce new bugs, which then "just appear" in a users' setup after a reboot
• Pulling on startup would lead to increased startup times (esp. if the images aren't needed for a pipeline, or images are pulled blocking)
• potentially waste space (depending on which images you pull, and which images the user uses)
• Risk users running into API-Limits (Pull limits) because of reboots, agent restarts and crashes
• You'd potentially override "manipulated" images, when a user did something to them and just tagged them the same, as to not change the configs (I know one should not do this, but trust me there are setups, where this is easier for an urgently needed fix)
• Introduce a new difference between the backends (does it also force pull for Kubernetes, which in some cases will just fail, as it may be prevented by cluster wide policies? how does it deal with podman,...)
• The "solution" is IMHO the wrong approach as changing released Tags after the fact calls for trouble... (e.g. I'm proxying all images (like many companies do), and prohibit tags from ever changing once they are present on that cache...)

If it's an "included" (hardcoded) image, the fix should be a new patch release (it's a fix after all).

[lafriks]

@gapodo it's common practice to use docker image versioning schema:

• :2 -> latest 2.x.y version (will change when new minor/patch version change)
• :2.0 -> latest 2.0.x version (will change when patch version change)
• :2.0.1 -> specific version (this should never change)

[gapodo]

@gapodo it's common practice to use docker image versioning schema:

• :2 -> latest 2.x.y version (will change when new minor/patch version change)
• :2.0 -> latest 2.0.x version (will change when patch version change)
• :2.0.1 -> specific version (this should never change)

I'm not disputing that this is commonly done (though highly frowned upon by many of the big players in the container field).

My concerns are mostly with "forced" updating (pulling) of images on startup and using floating tags for damage control.

There is a fairly high risk of breakage with even patch releases, as there is no full integation coverage, therefore updating a users system automatically should be considered dangerous / non-optimal.

If a image is hardcoded into the software, changing the image by manipulating the tag (or just pinning to a floating tag) and forcing "hidden" updates isn't the correct solution.

If there is complete trust in not breaking when updating, the version could even just be pinned at the major, as anything within minor and patch should (or if applying semver fully, must) be non breaking.

As someone who pinns his woodpecker to a next- things "just changing" isn't something at leas I would consider good. Also it "kills" the declarative part of the CI setup, if parts within are changing without the users intervention.

[lafriks]

this is just to pin default version, if you have such requirement for it not change you will pin specific version in your pipelines clone image property

[6543]

Ok we need a clear survay on that and decide on that + document

pin complete (🚀):

• pro: declarative
• con: if plugin get a fix we are forced to release a new woodpecker version

Pin majour&minor + pull (🎉 ):

• pro: no woodpecker release for fixes needed
• con: only declarative by option you manualy have to set

[6543]

-> complete pinning won by 12/8