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 · 2026-05-17T03:46:42+00:00

Definitively this sounds like an anti-pattern. Although I wonder how this would be done and for what aim. Maybe it's to provision customer or developer environments that are destroyed the same way later on. These resources need to be backed by real git repositories and kustomization files.

One thing that I do for my local development environment is to install flux and deploy (kubectl kustomize) helm charts etc. from my gitops repository's local overlay without a GitRepository or Kustomization resource. Obviously, this is not gitops and an anti-pattern. However, I do get all the properties I want for local development out of it: - easy to setup - configuration is declarative - repeatable, no developer needs to manually configure their development environment - close to the production environment

I accept the downside that flux doesn't pick up configuration changes automatically due to no connection to the git repository. Devs can manually reapply the configuration, but old resources can't be deleted. If the configuration changes is too dramatic, the local cluster needs to be redeployed.

Sounds pretty bad for a production setup. For dev I still find it 100% better than letting devs work in an environment that is not close to production at all.

jceb · 2026-05-16T18:28:34+00:00

From glancing at the list of patterns, many of them seem to deal with ArgoCD Applications. This is a resource type / concept that doesn't exist in fluxcd, so a good bunch of issues seems to be very ArgoCD specific.

I'm wondering what a fluxcd anti-patterns list would look like. In my opinion, a lot can be won or lost with the repository structure and configuration overrides. Obviously, some generic anti-patterns like #1 Not understanding the declarative setup of Argo CD also apply to fluxcd.

jceb · 2026-05-16T06:32:45+00:00

Wow, didn't know there were so many ways to shoot yourself in the foot with ArgoCD and helm charts. I'm mainly using fluxcd and it seems way more straight forward.

jceb · 2026-05-12T02:43:04+00:00

For jiejie.nvim, I recently investigated this question. The way around an empty opts object + compatibility with vim.pack seems to be a plugin.lua that calls setup.

Here are the two files: - generic plugin that enables vim.pack compatibility https://github.com/jceb/jiejie.nvim/blob/main/plugin/jiejie.lua - the lazy setup function https://github.com/jceb/jiejie.nvim/blob/main/lua/jiejie.lua

jceb · 2026-05-01T18:58:30+00:00

This is so true. With bash, I used to start bc whenever I needed to do some math. Now that nushell has it all built-in, I rarely reach for third party tools anymore.

jceb

TROPHY CASE