DEV Community: Abel Varga

Cluster Specific Template Overrides in ArgoCD ApplicationSets Using Cluster Generators

Abel Varga — Wed, 10 Aug 2022 08:36:00 +0000

Introduction

Creating ApplicationSets is a great tool dry up application templates in ArgoCD. You can generate similar applications where the only difference is the namespace for staging and production, or the labeling for tracks like canary and stable. So consider this use-case:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example-application
  namespace: argocd
spec:
  syncPolicy:
    preserveResourcesOnDeletion: true
  generators:
    - clusters:
        selector:
          matchLabels: #...
        values:
          env: staging
          track: stable
    - clusters:
        selector:
          matchLabels: #...
        values:
          env: production
          track: stable
    - clusters:
        selector:
          matchLabels: #...
        values:
          env: production
          track: canary
template:
  #...

These values are easy to set as they are mere strings. You can use simple interpolation to use these. In our case, we use several different values files based on these values in the template specs.

valueFiles:
  - values.yaml
  - 'values.{{values.env}}.yaml'
  - 'values.{{values.track}}.yaml'
  - 'secrets.{{values.env}}.yaml'

The Problem

This is all fine and dandy until you need something more complex. Imagine the case where you would like to set only one of these clusters to do automatic syncing. In our case, whenever we change the version in the helm chart, we'd like staging to be synced right away. We can set the syncPolicy, but its interface is an object, and you cannot interpolate that in a cluster specific way. To enable this we need to use the following:

syncPolicy:
  automated: {}

Where do you set these overrides if you want it to be merged only for staging for example?

The Solution

You can set template overrides in the cluster object. This will be merged with the template defined in this chart.

- clusters:
    selector:
      matchLabels: #...
    values:
      env: staging
      track: stable
    template:
      spec:
        syncPolicy:
          automated: {}

But one does not simply set template override, for some reason there are mandatory keys to be set, even if they are just placeholders. This means there is a minimal shape that you need to set to set anything for the cluster in hand. That looks like this:

  template:
+   metadata: {}
    spec:
+     project: app
+     destination: {}
+     source:
+       repoURL: http://github.com/example/helm-charts
      syncPolicy:
        automated: {}

So the staging cluster should look like this to be valid:

- clusters:
    selector:
      matchLabels: #...
    values:
      env: staging
      track: stable
    template:
      metadata: {}
      spec:
        project: web
        destination: {}
        source:
          repoURL: http://github.com/example/helm-charts
        syncPolicy:
          automated: {}

So there you go, if you're using cluster generators and would like a cluster specific override of the sync policy, now you know how to do that.

Why testing-library fails to do what it set out to do

Abel Varga — Wed, 08 Apr 2020 09:31:08 +0000

The problem that testing-library aims to solve is that when we write tests for our components, we rely upon the implementation details of said component, which in turn make our tests fragile, and not refactor proof. This goal is an admirable one and something which could help every developer to ship reliable and maintainable code.

The problem with this is not a conceptual one, but an execution one.

I was testing a custom input component because I found a bug. In a specific situation, the user could not type in it. Yes, it was a bug I introduced but thought before fixing it, I'll write tests to cover this. TDD, right? It turns out you cannot cover this scenario with react-testing-library and jest, because how it only partially implements a DOM.

What I needed was to test if, in the given situation, the user focuses the input and starts typing, the value of the input changes accordingly. The test has failed as it should have. So I began fixing the issue. It was quick and easy and could confirm the fix in my browser. When I went back to check up on my tests, they still failed.

My test consisted of using keyDown events to emulate typing. Because this is the user does, right? Well, it turns out that according to testing-library, the user is not pressing buttons, but fires change events! AS we all do when we do a Google search. We hit it up, and fire change event left and right and boom, here comes the search result.

My issue with this concept is that there are cases when firing a change event works, but pressing keys does not. And I could not find a solution for this since.

This issue is similar to not being able to query innerText because you'd need a layout engine for that. As if the user would be using your components without one. But worry not, there is data-test-id. Which is a way of saying, do not test implementation details, but implement details to test the thing.

I think while the concept is excellent, the tools are not in place to deliver yet. You still need puppeteer, playwright or selenium to get into the shoes of your end-user. If you know of any ways to run my existing testing-library specs in a browser a way that allows for querying elements by input text, like an xPath selector or something, and has a complete chain of events, please let me know.

Thank you, rant over

Optimize useEffect by using a condition as a dependency

Abel Varga — Fri, 03 Apr 2020 11:14:10 +0000

The useEffect hook is a great way to wrap side effects since the release of React 16.8. To quickly recap, this hook allows you to create functional components with behaviour akin to React classes' componentDidMount and componentDidUpdate.

But because of the way functional components work, this would mean performing a side effect on each render. This behaviour is suboptimal; hence dependency array was introduced. This array passed as the second argument of a useEffect call allows React to perform only when a reference passed in the dependency array changes.

While this is great in many cases when you need to perform a specific task when one of the dependencies changes, there are times when the reference update in itself does not mean the task in hand is needed. These are the cases when you add a condition to the function passed as the first argument. For example, when you want to update the state when a query is running. You want to run the effect when the query is running, but you do not need to run it when the state is already set to the correct value.

const { loading } = useQuery(query, { /*... */ })
const [state, setState] = useState('initial');

useEffect(() => {
  if (loading && state !== 'loading') setState('loading')
})

You cannot conditionally call useEffect or any other hook for that matter. In these cases, you add the condition in the function performing the side effect itself, while the variables checked in the condition go into the dependency array.

useEffect(() => {
  if (loading && state !== 'loading') setState('loading')
}, [loading, state])

Now to optimize even further, you need to think about what React is doing in the background. When you call useEffect, React checks your dependencies one-by-one. It has to, to be sure that your side effect takes place when any of the dependencies change. After this, your function runs and evaluates the condition it needs to. If it turns out that it needs to perform what it has to it's excellent, no time wasted. On the other hand, when it turns out, it does not have to perform anything, all React's work was in vain.

In the latter scenario, you can consider passing the condition evaluated right away. This way React only needs to check the one value in your dependencies, a boolean, and you already have the value ready for your function to decide whether it should perform or not.

const shouldSetStateToLoading = loading && state !== 'loading'
useEffect(() => {
  if (shouldSetStateToLoading) setState('loading')
}, [shouldSetStateToLoading])

The only caveat is that the condition itself needs to be cheaper then what React does. The odds are that it is.

You can check out the fiddle benchmark below:
https://jsfiddle.net/rangeoshun/j5a7qpbL/