Add example applicationset

[rklonner]

that uses a git generator.

The example will be used by a future example branch to demonstrate a refactoring process.

Closes #265

[rklonner]

@dag-andersen : Do you have an idea what can be the issue here in the PR check? Seems that edit-last fails when there is no comment yet.

Run gh pr comment 296 --repo dag-andersen/argocd-diff-preview --body-file output/diff.md --edit-last || \
no comments found for current user
GraphQL: Resource not accessible by integration (addComment)
Error: Process completed with exit code 1.

[dag-andersen]

@dag-andersen : Do you have an idea what can be the issue here in the PR check? Seems that edit-last fails when there is no comment yet.

Run gh pr comment 296 --repo dag-andersen/argocd-diff-preview --body-file output/diff.md --edit-last || \
no comments found for current user
GraphQL: Resource not accessible by integration (addComment)
Error: Process completed with exit code 1.

@rklonner

I believe this is because the pipeline is running from your "org" (account), using a token that does not have permission to post a comment on my "org" (account) 🤔 Maybe it easier if i just add the examples to the branches :) I can take them from the code snippet you showed in #265 (comment)

[rklonner]

@dag-andersen : Would it be possible to get the permission as I would have some more examples in mind I could add.

Or if it is too risky for you, can you trigger a rerun of the pipeline with your user when I open a PR to fix the check? Or is the account taken from the person who opened the PR?

[dag-andersen]

@rklonner

I just noticed that if we merge this, the ApplicationSet will start showing up as changed in, for example: #12

I would like to avoid this. Instead, I think we should create a new folder called use-cases, and then add self-contained examples inside it.

I suggest something like this:

tree ./examples
├── use-cases
│   └── refactoring
│       ├── appsets
│       │   └── my-app-set.yaml
│       └── my-service
│           ├── base
│           │   ├── deployment.yaml
│           │   ├── kustomization.yaml
│           │   └── service.yaml
│           └── overlay
│               ├── production
│               │   ├── kustomization.yaml
│               │   ├── memory_limit.yaml
│               │   └── replica_count.yaml
│               └── staging
│                   ├── kustomization.yaml
│                   └── memory_limit.yaml

And here it is as a pr: #298

Or if it is too risky for you, can you trigger a rerun of the pipeline with your user when I open a PR to fix the check? Or is the account taken from the person who opened the PR?

Sadly, I do not know how to solve that. I could create a GitHub PAT, but that always feels a bit insecure...

I think it might be easier if you just create the branches on your fork and point your documentation changes to your fork. When the docs are ready, it is very easy for me to pull your branches and push them to my repo, and then replace the account name in your command/code snippets :)

Does that make sense to you? What do you think?

What takes the most time is designing the examples and writing the docs. Copying branches and redirecting to another org or account is pretty fast, so I do not mind a bit of manual work on my end there.

[rklonner]

I just noticed that if we merge this, the ApplicationSet will start showing up as changed in, for example: #12

I would like to avoid this. Instead, I think we should create a new folder called use-cases, and then add self-contained examples inside it.

Could you outline a bit on that, I do not understand the root cause yet.

Is is because we are using it now as "monorepo" and would need to filter for applications we want to check? But why do the existing examples not interfere with each other? I thought that when the example gets merged and all examples branches get rebased the new applicationset should not be visible as changed, right? And in case there are no filters like file_regex applied - how is the new structure under examples/use-cases preventing that the examples interfere? It would be nice to reuse 2-3 example applications and deploy/refactor them in different ways and not copying them into self contained examples.

I think it might be easier if you just create the branches on your fork and point your documentation changes to your fork. When the docs are ready, it is very easy for me to pull your branches and push them to my repo, and then replace the account name in your command/code snippets :)

Does that make sense to you? What do you think?

Yes this would be fine for me - would just like to understand the underlying problem 😃

[dag-andersen]

@rklonner

Could you outline a bit on that

Yes!

In the kustomize-example-1 PR, we see how a change to:

• examples/kustomize/applications/my-service-prod.yaml
• examples/kustomize/my-service/base/deployment.yaml

triggers a render of:

• my-service-production (examples/kustomize/applications/my-service-prod.yaml)
• my-service-staging (examples/kustomize/applications/my-service-staging.yaml)

The "wow" moment here is that we get a render of the my-service-staging application because there is a change to examples/kustomize/my-service/base/deployment.yaml, even though there were no direct changes to my-service-staging.yaml itself.

So... let’s say we merge your PR. Then we will have two additional applications (my-service-app-set-production and my-service-app-set-staging) that also depend on the examples/kustomize/my-service/base/deployment.yaml file.

That means the moment I rebase kustomize-example-1 onto main, the workflow will rerun, and the output will now contain changes for all 4 applications: my-service-production, my-service-staging, my-service-app-set-production, and my-service-app-set-staging (all of which depend on examples/kustomize/my-service/base/deployment.yaml).

Hopefully this helps clarify what the “problem” is. Please let me know if anything is unclear, and I am happy to go into more detail 🚀

---

But why do the existing examples not interfere with each other?

Well 😅 that depends on what "examples" refers to.

Many of the other application manifests under /examples do overlap, meaning they reference files in other folders. However, the application manifests used in the "example pull requests" do not overlap.

Here I am referring to these:

These examples try to highlight a simple isolated example, without "noisy" changes to other Applications.

The /examples folder serves two main purposes in this repository:

1. Provide files that I can use in "PR examples" (for example kustomize-example-1 and helm-example-3). These are user-facing examples that help people understand how the tool works. In this case, it is beneficial to have completely separated code examples so they do not accidentally interfere with each other, and so I can add or delete them independently.

2. Provide files that I can use in the integration tests. The integration tests are mainly created by making changes to arbitrary files in the /examples folder and verifying that the output is correct. Here, it is beneficial to have very intertwined examples (where one change results in many applications being rendered), because it helps find edge cases. In this case, it is actually good that the examples interfere with each other.

Since your use case is to demonstrate something to the user, I would suggest creating isolated examples that clearly highlight the specific scenario the use case is designed around. At the same time, this helps avoid accidentally interfering with other user-facing examples.

Does this reasoning make sense to you? :)

[rklonner]

Hopefully this helps clarify what the “problem” is. Please let me know if anything is unclear, and I am happy to go into more detail 🚀

Thanks for the additional outline - now I know what I was missing. Was so into thinking about previewing changes on Argo manifests that I almost forgot that it of course also shows changes of applications itself and that we then have multiple Argo applications that point to the same k8s manifests... and then trigger also changes.

Was just a bit hard to digest for examples that seem to be also interconnected but are "just" close (like helm-example-3 and helm-example-2) 😄

Since your use case is to demonstrate something to the user, I would suggest creating isolated examples that clearly highlight the specific scenario the use case is designed around. At the same time, this helps avoid accidentally interfering with other user-facing examples.

So that means in the end we will have both areas, "use-cases" that are not interconnected to not interfere in PRs where we demonstrate functionality.

I will review the other PR, build future examples on that one.

Then we can close this one.