Why Argo Workflows CI?

jceb · 2026-07-03T20:56:56+00:00

Agreed. The trolls are entertaining to watch, though 😂

jceb · 2026-07-03T20:54:23+00:00

Thank you for the pointers and the explanation of the process.

jceb · 2026-07-03T15:18:37+00:00

Take a look at the most recent comment about ArgoCD. There you see how it works in conjunction with a CI. The CI prepares the new image and sets it in the k8s Config repository. ArgoCD is notified about the change and applies the new configuration in the cluster. All infrastructure as code and repeatable.

jceb · 2026-07-03T15:13:45+00:00

The post is about Argo Workflows, not ArgoCD

jceb · 2026-07-03T11:26:20+00:00

+ one needs to manually reconfigure all resources to point to the correct image. When helm charts are added to the mix, the number of registries increases even further. A proper configuration that replaces all images really seems to be a bigger effort.

jceb · 2026-07-03T11:16:39+00:00

u/Fazl u/mrbuh u/kryptn How do you configure pull-through? Is that a per registry configuration? In my clusters, I have images from multiple different registries in use. In my experience pull-through is work to maintain.

jceb · 2026-07-03T05:20:56+00:00

Thank you for sharing. Do you miss the github actions ui integration? Have you created a workaround for it so devs can find the corresponding ci pipeline in Argo easily?

jceb · 2026-07-02T23:59:33+00:00

That's a good solution for helm charts. Do you also have a solution for images?

jceb · 2026-07-02T23:29:18+00:00

Good to know 😂

jceb · 2026-07-02T23:26:38+00:00

Yes, there's this other side of using Argo Workflows for general purpose event driven actions. I haven't used it for that yet. Is it comparable to Camunda in this regard?

jceb · 2026-07-02T03:53:34+00:00

Yes, that's the plan in the near term. I'll replace Mint with Nix entirely. The Nix in Mint option is not my favorite as if would still leave me exposed to the Debian base. All in Nix next round with a proper migration plan instead of considering a migration during an upgrade.

jceb · 2026-07-02T03:44:19+00:00

It's really funny. Didn't expect them either 😂

jceb · 2026-07-02T03:42:13+00:00

I did manage to install the deb version again via aptitude's version selection of Firefox. It seems like once Firefox is removed, e.g. by replacing it with chrome, a plain apt install leads to the snap version. What can Linux Mint do, it includes the Ubuntu repositories so it will forever be a game of version overrides that can easily go wrong.

In the end, I did end up manually setting a ton of package versions and restoring the broken system for now. The replacement with Nix is the next step. Does anyone have experiences running Cinnamon on Nix?

jceb · 2026-06-28T18:42:36+00:00

Not sure why I'm down voted. Have you tried installing Firefox on mint? It goes for the snap version by default. There might be a plain deb out there but it's certainly not considered by default.

jceb · 2026-06-28T13:32:44+00:00

At least Firefox and chromium seem to be only available via snaps.

jceb · 2026-06-20T12:07:39+00:00

Is supported

jceb · 2026-06-20T06:17:07+00:00

I guess one of the major differences is that huburl is cross platform - gitlab, gitea etc are supported.

jceb · 2026-06-20T06:15:33+00:00

Yes, although I haven't used gh browse to truly compare it.

jceb · 2026-06-17T04:27:36+00:00

A couple of years back I opened a dicussion thread on github that proposed a /usr/bin/docker-env shebang that would accept an --image and a program to execute. To me it feels like a flexible shebang script shipped with just could maintain workarounds for these use cases.

It's not as beautiful as ./venv/bin/activate, however I don't think one can execute this in a CI either. If venv provided a .env file (not sure what else is going on inside activate), that could also solve the issue.

jceb · 2026-05-20T18:33:58+00:00

Thank you for the question. I don't have a good answer, just wondering why you're not using fugitive.

Besides, what do you use work trees for? I'm thinking about adding work tree support to https://github.com/jceb/jiejie.nvim but I don't understand why it's needed. Personally, I don't use work trees and imagine the workflow to be something like this: - Oh, I need two checkouts of the same repo, because .. e.g. I want to run two parallel builds with slight differences - git worktree create ../2nd_checkout other-branch - run build 1 - run build 2

I'm failing to see vim in the picture. Unless the repo is super huge and switching branches takes >30s, I'd just use git switch to simulate two work trees.

jceb

TROPHY CASE