I like it when articles on the Web start discussions. Although, sometimes such articles are just click bait, but you can figure it out based discussions they ignite.

Steve Smith wrote an article called "GitOps is a placebo", where he argues that GitOps haven't bought anything new to the table, because all its core concepts already existed in form of Continuous Delivery and Infrastructure as Code.

And here is the reply to this article by Carlos Sanchez in the form of a Twitter thread.

Feel free to share your own thoughts on GitOps in our chat

#cicd #iac #gitops

An article that saved me some time yesterday.

It's about how to append custom paths to the $PATH variable on a GitHub Actions runner. As you may guess, it's not simply $PATH.

However, you can do it as below:

 - run: echo "${HOME}/<YOUR_CUSTOM_BIN>" >> $GITHUB_PATH

#cicd #gha

A gist on how to escape a character in Jenkins

#cicd #jenkins

Here is the awesome list of GitHub Actions both official and community-driven.

So, if you were looking into working with GHA, that might be a good thing to check. Also, if you're using GHA already, you may find some common actions to remove some repeated lines of code in your pipelines.

P.S. If you are not interested in GitHub Actions, but still adore the idea of YAML based CI, I just want to remind you that you can use YAML to configure Jenkins pipelines as well

#cicd #github #gha #jenkins

From our subscribers.

Application Delivery Technical Advisory Group of CNCF released the v1.0.0 of GitOps specification.

You can find the specification itself on the GitHub.

Basically, a GitOps system should comply with 4 main principles:
1. Declarative: A system managed by GitOps must have its desired state expressed declaratively.
2. Versioned and Immutable: Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
3. Pulled Automatically: Software agents automatically pull the desired state declarations from the source. Agents within the system pull the desired state from the repository.
4. Continuously Reconciled: Software agents continuously observe the actual system state and attempt to apply the desired state.

You could kinda deduce these principles already, but now they’re formalized. Besides, you can adopt these principles and, well, GitOps not only for your services, but for IaC as well.

There are still open questions, for example, how to handle incidents in the immutable environment. However, I like the overall direction. Specifically the point that even though we switched to “cattle” servers from the “pet” ones, we still trat environments as “pets” and we need to stop that.

I see that demand for running dynamic environments increasing across the industry. So, this is definitely a valid point and an interesting area to explore.

#gitops #cicd #culture

​​Yet another post from the #app_bundle series. This is again a video from Viktor Farcic on how to combine ArgoCD, Crossplane, and KubeVela to completely abstract Kubernetes away from your product engineers aka developers and (allegedly) make their lives easier.

In the end of each year, many people make predictions on what upcoming times would look like. And I can say that abstracting clusters away will be a big thing in the industry. This brings us to the logical question: "So, why do all this stuff and not just use serverless options out of the box?". I will let you answer this question on your own.

P.S. You can save this post to blame me later, if this prediction happens to be wrong.

#kubernetes #cicd

One can create a lot of the automation based on GitHub labels. Also, labels are great indicators for the teammates and reviewers to indicate the status of a pull request.

Labeler GitHub action allows you to automate PR labeling. You can add specific labels based on the changed files. This would be useful for people who run trigger automation with labels. For example, you can add exclude-e2e-test label if only .md files have changed. Or if you’re running a monorepo, you can visually assign respective teams to code changes with automated labels.

There’s also a complementary tool for this Action called Retrolabeler, which can retrospectively label your PRs according to the Labeler rules.

#cicd #github

It's been a while since we had some practical materials here.

So, here's an article that helped me a lot today. It's about how to split outputs of a GitHub Actions step into an array that is suitable for a matrix property of a GHA job.

You see, the problem is that GHA don't have a native "split" functionality. So, you need a way to work around it. Moreover, that fromJson() function is important there, 'coz otherwise it doesn't work.

This could be useful if you need to run multiple jobs based on, for example, changed files. Also, here's a bonus article on how to get the changed files in GHA without 3rd party Actions.

P.S. Well... One can hate Jenkins until they need to write some more or less custom logic in a YAML-based CI.

#github #cicd

GitLab is adopting FluxCD as its GitOps engine.

This is process has just started. So, GitLab's own Kubernetes agents remain the same and, according to this article, likely won't be deprecated till 2025. However, the GitOps functionality is transitioned into the maintenance mode.

Also, this article contains the justification behind Flux. Mainly, it was chosen because it fully relies on Kubernetes API, while Argo provides it's own API and UI, which is harder for GitLab folks to integrate into their own product.

#cicd #gitops #gitlab #kubernetes

Remember that a couple of years ago GitHub has disabled automatic execution for its Actions?

The idea behind this decision is more or less described in this article - Build Pipeline Security. The problem described in this article is not some sort of a rocket science. Thus, any malicious actor can do something similar.

This brings me to the topic of CI integrations for public repositories. I think on some podcast or in some article I’ve heard an advice for the beginners to create their pet project and configure CI for it. So, you can show that you have some practical experience. Ok, GitHub has you covered, but what about other CIs which are available for public repositories? Thus, I might have been a good advice, if we were living in the world here all the people are kind to each other, which is not the case.

Does it mean that you cannot have a CI for your pet-project? Of course, not! Just be careful with what it actually can execute on each step. The author of the linked article suggests putting deploy scripts into a separate private repository. I think, nowadays any major VCS vendor allows one to have at least one private repository for free.

Yet, I would say that this is not good enough and you should also make sure that you should follow GitHub’s steps and enforce a mandatory approvals for CI runs as well as have some quotas in place for the compute resources available for your CI. Again, GitHub has you covered here, but if you want to use something else, you are on your own.

#cicd #security #github #aws

Some good practices for Argo Workflows. I'm not super familiar with this tool, so I'd just list the points here:

- Use common templates
- Limit parallelism to control cluster resources
- Avoid nested loops
- Collect metrics from your workflows
- Use lifecycle hooks
- Control long-running workflows or break down long workflows into separate smaller ones
- Integrate with Argo Events

#argocd #cicd #kubernetes

Here’s some original content, folks!

I wrote an article on how to create a workflow in GitHub Actions that is triggered with a comment.

There are some caveats with such workflows in GHA. Also, you have to do some additional tweaks to make it better from the UX perspective.

You can read the article:

- In my blog
- On Substack

Hope, you’ll enjoy it!

#github #cicd

I have updated my article on triggering GHA workflows with comments.

Recently, I have found another caveat that has really bitten me in the ass. You can look for the keywords UPD 2023-09-07 on the page.

As usual, you can read it:

- In my blog
- On Substack

#cicd #github

An overview of the progressive delivery principle by Buoyant.

There's also a comparison between Flagger and Argo Rollouts, which are probably the most famous (if not the only) tools designed for progressive delivery.

Now, Buoyant is the company behind Linkerd. So, obviously, their examples are based on Linkerd. However, you don't need any service mesh to adopt this technique. Service mesh will only help you with smarter traffic splitting.

Also, there's an error in this article: it claims that Flagger works with existing deployments, while Argo Rollouts requires its special CRD, which is only partially true. Argo Rollouts can also work with existing Deployment objects. So, in these regards, both tools are the same.

If you prefer a video format, I would also suggest watching a talk about progressive delivery by Carlos Sanchez at Fosdem 2024. There you can see Argo Rollouts in action.

#cicd

You might have heard that the WeaveWorks has gone out of business.

Yet, they did a right thing and open sourced their GitOps Enterprise product, which previously was only accessible to the paid customers.

#cicd #gitops

S3 cache for GitHub Actions - a drop-in replacement for the native GHA cache functionality that is technically unlimited because of S3.

I haven’t used it personally and I don’t have an AWS account to test it. This thing comes as a part of RunsOn - a solution to setup your self-hosted runners for GHA in AWS.

Might be worth checking if you want to bring your own worker nodes to GHA but don’t want the hustle configuring them.

#github #gha #cicd

A neat comparison between Argo and Flux.

I like the fact that the article mostly focuses on UX and use cases. Yet, I would disagree with this statement here:

 would deploy one Argo CD per tenant, where each tenant is an independent developer team with their applications, but it can work with multiple clusters, for example, dev/stage/prod, etc.

I mean sure. If you have enough resources, go for it! However, I witnessed how getting down from “Argo per team” to “just one Argo” reduced resource consumption in a cluster by 90%.

#cicd #gitops

Some lightweight read for you on Friday.

From the 80's to 2024 - how CI tests were invented and optimized sneak peeks into the history of automated testing. And evaluates possible future avenues where testing strategies could go.

Fun fact: Jenkins is apparently 20 years old. I didn't know that :D
Another fun fact: we had a voice chat about Jenkins recently. Yet, I still need to find some mental power to edit it.

#cicd

At last! A new issue of our Voice Chat is out! It took me way longer, because I had to switch from Davinci Resolve to Kdenlive, since Davinci doesn't really work on Linux despite their claims.

In any case, here we are. We talked about Jenkins this time: who uses it, why is it still in use, and what alternatives would we use instead.

The voice chat is in Ukrainian and is available on:

- YouTube
- Substack
- Spotify
- Apple Podcasts
- or via a direct RSS feed

#voice_chat #cicd #jenkins

A nice read about ArgoCD.

What I especially liked about it is that it goes beyond your typical “hello world” examples and also touches topics like multi cluster deploys, app-of-apps pattern, and encryption.

#argocd #cicd