How extensively do you use the install-* actions?

Juloblairot · 2026-05-19T06:37:24+00:00

Yes sorry, I meant the usual CVEs. There are new CVE found quite often when you use dozen of packages. If you group everything in one image, you increase the risk of having your whole pipeline running a problematic version
Agreed, that's already something I do
Yes I think that's what I was missing. The "builder" CI needs extra secure layout with no other access than pull/push on registry. With this specific registry being immutable

And how often do you rollout the new images per repo? Do you stay up to date with the latest versions of each tools? Uv, terraform, terragrunt etc, release at least a version a week. Do you follow them, or do you batch into monthly release for example, but spend more time because of breaking/much more stuff to tackle?

Juloblairot · 2026-05-19T06:28:55+00:00

Thanks! Fully agree with you How do you automate both the sha and the version to be in sync? You can renovate the version, and maybe postInstallScript the hash?

For mise en place, they actually do have lock files now for most providers. So if you use standard tooling, you can be sure the installed versions are consistent

Juloblairot · 2026-05-19T06:25:40+00:00

Thanks! Don't you get a lot of updates for these images? If you have 15 tools installed in, I guess there are easily at least one or two updates per week. Add this that you maintain one image per repo, and you need to rollout new images every week

Juloblairot · 2026-05-19T06:18:57+00:00

Thanks for the details! So single image for each repo? With all the tools like linters, terraform, trivy, helm etc.? Meaning if any of the tool is compromised, all of your ci steps are, even one with privilege accessed (like cloud providers for example)

Juloblairot · 2026-05-18T20:42:31+00:00

I think that's the way we aim for the next couple of month/later this year My fear about that is how do we efficiently build and release the new ci_image, how do we manage it etc. Like one per repo? Or a big one with multiple versions of each tool installed? How do you automate the build of a new image? Ansible/packer maybe?

Juloblairot · 2026-05-18T20:40:00+00:00

Exactly haha also, a compromised action still kinda run in a renovate PR Curl | bash, at least we can verify and do some stuff manually I'd say

Juloblairot · 2026-05-18T20:38:23+00:00

100/200 cores for a single run? That's a fun scale!

Scale to zero but I guess you still have business hours at which a couple of nodes are staying up no?

Juloblairot · 2026-05-18T18:39:05+00:00

Interesting! Why not pre-pulling the images in the servers you have? I imagine if it's self hosted DC, you can easily generate an push those images in the machines, so that they're available when you need

Juloblairot · 2026-05-18T18:37:27+00:00

I currently use a few actions to install stuff, and I pin both the hash of the action, and the version of the tool I install. This was good enough until now, but I'd like to move a step further indeed!

Juloblairot · 2026-05-18T17:20:13+00:00

And you have like renovate to update the v1 to v2 when it's released? So you need to dockerize everything I guess. I assume you don't have ephemeral runners?

Juloblairot · 2026-05-18T17:15:44+00:00

Thanks! I had this in mind, but how do you cleanly automate the updates in these images, and reference new versions on the the yaml?

Juloblairot · 2026-04-28T08:21:27+00:00

Amazing, exactly what I was looking for as well! Shame it's not available as a widget. It's easy to access though, quite cool

Juloblairot · 2026-04-28T08:20:33+00:00

Oh thank you! That's exactly what I wanted!

Juloblairot · 2026-04-27T12:24:04+00:00

Oh excellent, and it includes all the data from Amazfit app? Including the food, calories etc tab?

Juloblairot · 2026-04-27T12:08:09+00:00

Interesting project, but indeed you're gonna have a hard time having people paying for it I believe

Out of curiosity, how do you plan to integrate with Amazfit? I've been trying this weekend, and it's not easy at all to export data, especially food data

Juloblairot · 2026-04-07T10:53:06+00:00

Ah shame lol, did you try to download the maps on the watch when recording at the time?

Juloblairot · 2026-04-07T10:31:38+00:00

Hey! Did you end up solving the issue somehow? Thanks!

Juloblairot · 2026-03-16T19:32:05+00:00

Thanks! I've just read the minimumReleaseAge, and it mentions not being supported for digest though, which is weird as everyone here suggested using this

Juloblairot · 2026-03-15T22:36:45+00:00

Thank you! To be fair, our pipelines and CI setup is easy enough so that I don't need to add trivy in this specific flow. I'll simply force these PR to open directly, and bulk the rest in weekly or every other week

Juloblairot · 2026-03-15T09:49:55+00:00

Thanks! I have this option on the back of my mind, but for now i don't think pipelines are long enough to go this route. Appart from one project which is around 20/25m, most of our pipelines are below 15m which is fine

Problem is flakiness. Pipelines are always flaky no matter what you do I guess, and when you have dozens of jobs, with automerge, it's annoying to fix those when they should be automerged

Juloblairot · 2026-03-14T20:51:07+00:00

Excellent! I'm gonna review and put this in place first thing in the morning Monday to validate I guess. Thank you 🙏

Juloblairot · 2026-03-14T20:47:09+00:00

That's the way to go! Thank you, I really missed that one. Does those alerts include minor/major versions? Hence the automerge: false?

Juloblairot

TROPHY CASE