### ApplicationSet Controller Startup Logs

Source: https://github.com/argoproj/applicationset/blob/master/docs/Development.md

Example output indicating the ApplicationSet controller has started successfully and is running its workers.

```text
INFO	controller-runtime.controller	Starting Controller	{"controller": "applicationset"}
INFO	controller-runtime.controller	Starting workers	{"controller": "applicationset", "worker count": 1}
```

--------------------------------

### Install ApplicationSet (pre-Argo CD v2.3)

Source: https://github.com/argoproj/applicationset/blob/master/docs/Getting-Started.md

Use this command to install the ApplicationSet controller into an existing Argo CD installation for versions prior to v2.3. Ensure Argo CD is installed in the 'argocd' namespace.

```bash
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/applicationset/v0.4.0/manifests/install.yaml
```

--------------------------------

### Install Development Build of ApplicationSet Controller

Source: https://github.com/argoproj/applicationset/blob/master/README.md

Use this command to install the latest development build of the ApplicationSet controller. This command applies the installation manifest directly from a GitHub URL.

```bash
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/applicationset/master/manifests/install.yaml
```

--------------------------------

### Build and Serve Docs Locally

Source: https://github.com/argoproj/applicationset/blob/master/docs/Development.md

Commands to install documentation dependencies and build/serve the documentation locally.

```bash
pip3 install -r docs/requirements.txt
make build-docs-local
make serve-docs-local
```

--------------------------------

### Git Directory Generator Example

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

This example demonstrates how to use the Git directory generator to create Application resources based on subdirectories within a Git repository. It dynamically deploys workloads defined in these directories.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-addons
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/argoproj/applicationset.git
      revision: HEAD
      directories:
      - path: examples/git-generator-directory/cluster-addons/*
  template:
    metadata:
      name: '{{path[0]}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
```

--------------------------------

### Applying Resources with kubectl

Source: https://github.com/argoproj/applicationset/blob/master/examples/clusterDecisionResource/README.md

Applies the PlacementDecision, ConfigMap, and ducktype example resources using kubectl.

```bash
kubectl apply -f ./placementdecision.yaml
kubectl apply -f ./configMap.yaml
kubectl apply -f ./ducktype-example.yaml
```

--------------------------------

### Basic List Generator Example

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-List.md

This example demonstrates targeting a local cluster named 'engineering-dev' using the List generator. The 'cluster' and 'url' fields are passed as parameters to the template.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  namespace: argocd
spec:
  generators:
  - list:
      elements:
      - cluster: engineering-dev
        url: https://kubernetes.default.svc
#     - cluster: engineering-prod
#       url: https://kubernetes.default.svc
#       foo: bar
  template:
    metadata:
      name: '{{cluster}}-guestbook'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        path: examples/list-generator/guestbook/{{cluster}}
      destination:
        server: '{{url}}'
        namespace: guestbook

```

--------------------------------

### Merge Generator Example with Clusters and List

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Merge.md

This example demonstrates using the Merge generator to combine parameters from a base Cluster generator, an override Cluster generator, and a List generator. It shows how to define merge keys and override values for specific clusters.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-git
spec:
  generators:
    # merge 'parent' generator
    - merge:
        mergeKeys:
          - server
        generators:
          - clusters:
              values:
                kafka: 'true'
                redis: 'false'
          # For clusters with a specific label, enable Kafka.
          - clusters:
              selector:
                matchLabels:
                  use-kafka: 'false'
              values:
                kafka: 'false'
          # For a specific cluster, enable Redis.
          - list:
              elements: 
                - server: https://2.4.6.8
                  values.redis: 'true'
  template:
    metadata:
      name: '{{name}}'
    spec:
      project: '{{metadata.labels.environment}}'
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        path: app
        helm:
          parameters:
            - name: kafka
              value: '{{values.kafka}}'
            - name: redis
              value: '{{values.redis}}'
      destination:
        server: '{{server}}'
        namespace: default

```

--------------------------------

### Example JSON Configuration File

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

This JSON file contains cluster-specific information that will be parsed by the Git file generator to create parameters.

```json
{
  "aws_account": "123456",
  "asset_id": "11223344",
  "cluster": {
    "owner": "cluster-admin@company.com",
    "name": "engineering-dev",
    "address": "https://1.2.3.4"
  }
}
```

--------------------------------

### Update Getting-Started.md for Release Version

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Modify the Getting-Started.md file to reference the new release version in installation commands. This involves replacing 'master' with the version tag (e.g., 'v0.1.0') in kubectl apply URLs.

```shell
# Replace
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/applicationset/master/manifests/install.yaml
# with
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/applicationset/v0.1.0/manifests/install.yaml
```

--------------------------------

### Example Status Format 1

Source: https://github.com/argoproj/applicationset/blob/master/examples/clusterDecisionResource/README.md

A common status format for cluster information.

```yaml
status:
  clusters:
  - name: cluster-01
  - name: cluster-02
```

--------------------------------

### Example Status Format 2

Source: https://github.com/argoproj/applicationset/blob/master/examples/clusterDecisionResource/README.md

An alternative status format for cluster information.

```yaml
status:
  decisions:
  - clusterName: cluster-01
    namespace: cluster-01
  - clusterName: cluster-02
    namespace: cluster-02
```

--------------------------------

### ApplicationSet with Cluster Generator

Source: https://github.com/argoproj/applicationset/blob/master/README.md

This example demonstrates a typical ApplicationSet configuration using the cluster generator. It defines how to produce a list of values from clusters and use them to parameterize an Argo CD Application template.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - clusters: {} # This is a generator, specifically, a cluster generator.
  template: 
    # This is a template Argo CD Application, but with support for parameter substitution.
    metadata:
      name: '{{name}}-guestbook'
    spec:
      project: "default"
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps/
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{server}}'
        namespace: guestbook
```

--------------------------------

### Run ApplicationSet Controller from CLI

Source: https://github.com/argoproj/applicationset/blob/master/docs/Development.md

Starts the ApplicationSet controller as a standalone process from the command line. This is useful for iterative development. Ensure Argo CD is running and port 8081 is exposed.

```bash
./dist/argocd-applicationset --metrics-addr=":18081" --probe-addr=":18082" --argocd-repo-server=localhost:8081 --debug  --namespace=argocd
```

--------------------------------

### Example of Custom Annotation on Application

Source: https://github.com/argoproj/applicationset/blob/master/docs/Controlling-Resource-Modification.md

Illustrates an Application with a custom annotation not present in the parent ApplicationSet template, which will be reverted by the controller.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations: 
    # This annotation exists only on this Application, and not in 
    # the parent ApplicationSet template:
    my-custom-annotation: some-value
spec:
  # (...)
```

--------------------------------

### Modify ApplicationSet Installation Manifest

Source: https://github.com/argoproj/applicationset/blob/master/docs/Controlling-Resource-Modification.md

Alternatively, edit the `install.yaml` manifest file used for ApplicationSet installation. After cloning the repository and checking out the correct version, modify the deployment configuration within `install.yaml` and then apply the changes to your cluster.

```bash
# Clone the repository
git clone https://github.com/argoproj/applicationset

# Checkout the version that corresponds to the one you have installed.
git checkout "(version of applicationset)"
# example: git checkout "0.1.0"

cd applicationset/manifests

# open 'install.yaml' in a text editor, make the same modifications to Deployment 
# as described in the previous section.

# Apply the change to the cluster
kubectl apply -n argocd -f install.yaml
```

--------------------------------

### ApplicationSet with SCM Provider Generator

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-SCM-Provider.md

Example of an ApplicationSet resource using the scmProvider generator. This configuration defines how to fetch repository information and use it to template application specifications.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - scmProvider:
    # ...
  template:
    metadata:
      name: '{{ repository }}'
    spec:
      source:
        repoURL: '{{ url }}'
        targetRevision: '{{ branch }}'
        path: kubernetes/
      project: default
      destination:
        server: https://kubernetes.default.svc
        namespace: default

```

--------------------------------

### ApplicationSet Git Generator for Self-Service

Source: https://github.com/argoproj/applicationset/blob/master/docs/Use-Cases.md

This example demonstrates an ApplicationSet configuration using a Git generator. It restricts certain fields like 'project', 'cluster', and 'namespace' while allowing developers to customize source repository details via JSON files.

```yaml
kind: ApplicationSet
# (..)
spec:
  generators:
  - git:
      repoURL: https://github.com/argoproj/applicationset.git
      files:
      - path: "apps/**/config.json"
  template:
    spec:
      project: dev-team-one # project is restricted
      source:
        # developers may customize app details using JSON files from above repo URL
        repoURL: {{app.source}}
        targetRevision: {{app.revision}}
        path: {{app.path}}
      destination:
        name: production-cluster # cluster is restricted
        namespace: dev-team-one # namespace is restricted
```

--------------------------------

### Generator Template Override Example

Source: https://github.com/argoproj/applicationset/blob/master/docs/Template.md

This example demonstrates how a generator's template can override fields from the spec-level template, specifically the 'path' in this case.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - list:
      elements:
        - cluster: engineering-dev
          url: https://kubernetes.default.svc
      template:
        metadata: {}
        spec:
          project: "default"
          source:
            revision: HEAD
            repoURL: https://github.com/argoproj/applicationset.git
            # New path value is generated here:
            path: 'examples/template-override/{{cluster}}-override'
          destination: {}

  template:
    metadata:
      name: '{{cluster}}-guestbook'
    spec:
      project: "default"
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        # This 'default' value is not used: it is is replaced by the generator's template path, above
        path: examples/template-override/default
      destination:
        server: '{{url}}'
        namespace: guestbook
```

--------------------------------

### Create Release Branch

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Create a new release branch from the master branch. Ensure the branch name starts with 'release-'.

```shell
git remote add upstream git@github.com:argoproj/applicationset # Use a different upstream here for testing purposes
git fetch upstream
git checkout master
git reset --hard upstream/master

git checkout -b "release-(VERSION)"
# Example: git checkout -b "release-0.1.0"
# Branch name must begin with 'release-'
```

--------------------------------

### Example Argo CD Application Resource

Source: https://github.com/argoproj/applicationset/blob/master/docs/index.md

This YAML defines an Argo CD Application resource generated by an ApplicationSet. It shows how parameters like cluster name and URL are substituted into the source path and destination server fields.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: engineering-dev-guestbook
spec:
  source:
    repoURL: https://github.com/infra-team/cluster-deployments.git
    targetRevision: HEAD
    path: guestbook/engineering-dev
  destination:
    server: https://1.2.3.4
    namespace: guestbook
```

--------------------------------

### Cluster Generator Template Example

Source: https://github.com/argoproj/applicationset/blob/master/docs/Template.md

This snippet shows the template subfield within a Cluster generator, defining metadata and spec for an Argo CD Application.

```yaml
# (...)
 template:
   metadata:
     name: '{{cluster}}-guestbook'
   spec:
     source:
       repoURL: https://github.com/infra-team/cluster-deployments.git
       targetRevision: HEAD
       path: guestbook/{{cluster}}
     destination:
       server: '{{url}}'
       namespace: guestbook
```

--------------------------------

### Accessing Application via NodePort Service

Source: https://github.com/argoproj/applicationset/blob/master/examples/git-generator-directory/excludes/cluster-addons/exclude-helm-guestbook/templates/NOTES.txt

This snippet provides commands to get the NodePort and Node IP, then constructs the application URL for NodePort services. It requires kubectl to retrieve service and node information.

```bash
export NODE_PORT=$(kubectl get --namespace {{ .Release.Namespace }} -o jsonpath="{.spec.ports[0].nodePort}" services {{ template "helm-guestbook.fullname" . }})
export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
echo http://$NODE_IP:$NODE_PORT
```

--------------------------------

### Exclude Specific Directory with Git Generator

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

This example demonstrates how to exclude a specific directory ('exclude-helm-guestbook') from being scanned by the Git directory generator. Exclude rules take precedence over include rules.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-addons
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/argoproj/applicationset.git
      revision: HEAD
      directories:
      - path: examples/git-generator-directory/excludes/cluster-addons/*
      - path: examples/git-generator-directory/excludes/cluster-addons/exclude-helm-guestbook
        exclude: true
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
```

--------------------------------

### ApplicationSet with Cluster Decision Resource Generator

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Cluster-Decision-Resource.md

Example of an ApplicationSet using the clusterDecisionResource generator. It specifies a ConfigMap for duck-type GVK information and uses either 'name' or 'labelSelector' to identify the resource. The 'requeueAfterSeconds' field controls the update frequency.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
 name: guestbook
 namespace: argocd
spec:
 generators:
 - clusterDecisionResource:
    # ConfigMap with GVK information for the duck type resource
    configMapRef: my-configmap  
    name: quak           # Choose either "name" of the resource or "labelSelector"
    labelSelector:
      matchLabels:
        duck: spotted
      matchExpressions:
      - key: duck
        operator: In
        values:
        - "spotted"
        - "canvasback"   
    # OPTIONAL: Checks for changes every 60sec (default 3min)
    requeueAfterSeconds: 60
 template:
   metadata:
     name: '{{name}}-guestbook'
   spec:
      project: "default"
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps/
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{clusterName}}' # 'server' field of the secret
        namespace: guestbook

```

--------------------------------

### Duck-typed Resource for Cluster Decisions

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Cluster-Decision-Resource.md

An example of a custom resource ('quak') that the Cluster Decision Resource generator can reference. The generator specifically looks for the 'decisions' list within the resource's status to determine cluster information.

```yaml
apiVersion: mallard.io/v1beta1
kind: Duck
metadata:
  name: quak
spec: {}
status:
  # Duck-typing ignores all other aspects of the resource except 
  # the "decisions" list
  decisions:
  - clusterName: cluster-01
  - clusterName: cluster-02

```

--------------------------------

### Accessing Application via ClusterIP Service

Source: https://github.com/argoproj/applicationset/blob/master/examples/git-generator-directory/excludes/cluster-addons/exclude-helm-guestbook/templates/NOTES.txt

This snippet provides commands to get the pod name and then uses kubectl port-forward to access the application locally. It assumes the application is accessible via port 8080.

```bash
  export POD_NAME=$(kubectl get pods --namespace {{ .Release.Namespace }} -l "app={{ template "helm-guestbook.name" . }},release={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80
```

--------------------------------

### Build and Push ApplicationSet Image

Source: https://github.com/argoproj/applicationset/blob/master/docs/Development.md

Builds and pushes the ApplicationSet controller container image to a specified registry. Ensure you have logged in to your container registry beforehand.

```bash
# Build and push the image to container registry
IMAGE="(username)/argocd-applicationset:v0.0.1" make image-push
```

--------------------------------

### Build Release Candidate

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Build the release artifact using 'make build', specifying the container registry, image namespace, and tag. Use placeholder values for version.

```bash
CONTAINER_REGISTRY=quay.io IMAGE_NAMESPACE=argoproj IMAGE_TAG=v(version)  make build
# example: CONTAINER_REGISTRY=quay.io IMAGE_NAMESPACE=argoproj IMAGE_TAG=v0.1.0  make build
```

--------------------------------

### Push Container Image

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Log in to the container registry and push the built container image using the make command. Ensure the correct container registry and image tag are specified.

```shell
docker login (container registry)
# Example: docker login quay.io
#   Username: myusername
#   Password: mypassword

make CONTAINER_REGISTRY='quay.io' IMAGE_TAG='(VERSION)'  image-push
# Example: make CONTAINER_REGISTRY='quay.io' IMAGE_TAG='v0.1.0'  image-push
```

--------------------------------

### Deploy ApplicationSet Controller Manifests

Source: https://github.com/argoproj/applicationset/blob/master/docs/Development.md

Deploys the Kubernetes manifests for the ApplicationSet controller Deployment. This command assumes the image has already been built and pushed.

```bash
# Deploy the ApplicationSet controller manifests
IMAGE="(username)/argocd-applicationset:v0.0.1" make deploy
```

--------------------------------

### Cluster Secret Structure

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Cluster.md

An example of the structure of a Kubernetes Secret used to store Argo CD cluster information. The 'data' fields are base64 encoded in actual Kubernetes Secrets.

```yaml
kind: Secret
data:
  # Within Kubernetes these fields are actually encoded in Base64; they are decoded here for convenience.
  # (They are likewise decoded when passed as parameters by the Cluster generator)
  config: "{'tlsClientConfig':{'insecure':false}}"
  name: "in-cluster2"
  server: "https://kubernetes.default.svc"
metadata:
  labels:
    argocd.argoproj.io/secret-type: cluster
# (...)
```

--------------------------------

### Accessing Application via Ingress Hosts

Source: https://github.com/argoproj/applicationset/blob/master/examples/git-generator-directory/excludes/cluster-addons/exclude-helm-guestbook/templates/NOTES.txt

This snippet shows how to construct the application URL when ingress is enabled and hosts are configured. It iterates through the defined hosts and prepends the protocol and path.

```go-template
{{- if .Values.ingress.enabled }}
{{- range .Values.ingress.hosts }}
  http{{ if $.Values.ingress.tls }}s{{ end }}://{{ . }}{{ $.Values.ingress.path }}
{{- end }}
{{- end }}
```

--------------------------------

### ApplicationSet with Git File Generator

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

This ApplicationSet resource uses the Git file generator to discover configuration files and dynamically create applications. The parameters from the discovered files are used to populate the application template.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/argoproj/applicationset.git
      revision: HEAD
      files:
      - path: "examples/git-generator-files-discovery/cluster-config/**/config.json"
  template:
    metadata:
      name: '{{cluster.name}}-guestbook'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        path: "examples/git-generator-files-discovery/apps/guestbook"
      destination:
        server: '{{cluster.address}}'
        namespace: guestbook
```

--------------------------------

### Invalid Merge Generator Configuration: Template Override on Child Generator

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Merge.md

This example demonstrates an invalid configuration where a 'template' override is specified on a child generator within the merge generator. This 'template' will not be processed.

```yaml
- merge:
    generators:
      - list:
          elements:
            - # (...)
          template: { } # Not processed

```

--------------------------------

### ApplicationSet with List Generator

Source: https://github.com/argoproj/applicationset/blob/master/docs/index.md

Defines an ApplicationSet resource to deploy a 'guestbook' application to a predefined list of Kubernetes clusters. Parameters from the list are substituted into the template.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - list:
      elements:
      - cluster: engineering-dev
        url: https://1.2.3.4
      - cluster: engineering-prod
        url: https://2.4.6.8
      - cluster: finance-preprod
        url: https://9.8.7.6
  template:
    metadata:
      name: '{{cluster}}-guestbook'
    spec:
      source:
        repoURL: https://github.com/infra-team/cluster-deployments.git
        targetRevision: HEAD
        path: guestbook/{{cluster}}
      destination:
        server: '{{url}}'
        namespace: guestbook
```

--------------------------------

### Invalid Merge Generator Configuration: Nested Combination Generators

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Merge.md

This example illustrates an invalid configuration where combination-type generators (Matrix or Merge) are nested more than once. The third level of nesting for a merge generator is not supported.

```yaml
- merge:
    generators:
      - merge:
          generators:
            - merge:  # This third level is invalid.
                generators:
                  - list:
                      elements: 
                        - # (...)

```

--------------------------------

### Log in to Quay.io

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Authenticate with Quay.io using your username and password before pushing container images.

```bash
docker login quay.io -u argocdapplicationset -p (password)
```

--------------------------------

### Prevent Application Deletion with --policy create-update

Source: https://github.com/argoproj/applicationset/blob/master/docs/Controlling-Resource-Modification.md

Use the `--policy create-update` parameter to allow the ApplicationSet controller to create or modify Application resources, but prevent their deletion.

```bash
--policy create-update
```

--------------------------------

### Cluster Secret with Staging Label

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Cluster.md

An example of an Argo CD cluster secret that would be matched by the 'staging: true' label selector. It includes the required 'argocd.argoproj.io/secret-type: cluster' label along with the custom 'staging' label.

```yaml
kind: Secret
data:
  # (... fields as above ...)
metadata:
  labels:
    argocd.argoproj.io/secret-type: cluster
    staging: "true"
# (...)
```

--------------------------------

### Accessing Application via LoadBalancer Service

Source: https://github.com/argoproj/applicationset/blob/master/examples/git-generator-directory/excludes/cluster-addons/exclude-helm-guestbook/templates/NOTES.txt

This snippet shows how to retrieve the LoadBalancer IP and construct the application URL. It includes a note about potential delays in LoadBalancer IP availability and a command to monitor service status.

```bash
     NOTE: It may take a few minutes for the LoadBalancer IP to be available.
           You can watch the status of by running 'kubectl get svc -w {{ template "helm-guestbook.fullname" . }}'
  export SERVICE_IP=$(kubectl get svc --namespace {{ .Release.Namespace }} {{ template "helm-guestbook.fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  echo http://$SERVICE_IP:{{ .Values.service.port }}
```

--------------------------------

### Invalid Merge Generator Configuration: Multiple Generators in One Entry

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Merge.md

This example shows an invalid configuration where multiple generators are specified within a single array entry for the merge generator. The controller will report an error on generation.

```yaml
- merge:
    generators:
     - list: # (...)
       git: # (...)

```

--------------------------------

### Dry Run: Release Script

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Execute the release script with custom image namespace and registry for a dry run. Ensure you substitute your own username and version.

```bash
CONTAINER_REGISTRY=quay.io IMAGE_NAMESPACE=(your-quay.io-usename) ./hack/release.sh (version)
```

```bash
CONTAINER_REGISTRY=quay.io IMAGE_NAMESPACE=jgwest-redhat ./hack/release.sh 0.1.0
```

--------------------------------

### Dry Run: Push Image

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Push the built container image using 'make image-push', specifying your Quay.io username and the version tag.

```bash
make IMAGE_NAMESPACE=(your-quay.io-usename)  CONTAINER_REGISTRY='quay.io' IMAGE_TAG='(version)'  image-push
```

```bash
make IMAGE_NAMESPACE=jgwest-redhat  CONTAINER_REGISTRY='quay.io' IMAGE_TAG='v0.1.0'  image-push
```

--------------------------------

### Prevent Application Modification or Deletion with --policy create-only

Source: https://github.com/argoproj/applicationset/blob/master/docs/Controlling-Resource-Modification.md

Use the `--policy create-only` parameter to allow the ApplicationSet controller to create Application resources but prevent any further modification or deletion.

```bash
--policy create-only
```

--------------------------------

### Run Release Script

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Execute the release.sh script to perform release tasks such as updating the VERSION file, regenerating CRDs and manifests, and creating a git commit. Specify the container registry, image namespace, and version.

```shell
CONTAINER_REGISTRY=quay.io IMAGE_NAMESPACE=argoproj hack/release.sh (VERSION)
# Example: CONTAINER_REGISTRY=quay.io  IMAGE_NAMESPACE=argoproj hack/release.sh 0.1.0
```

--------------------------------

### Corrected Exclude/Include Rule Order

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

Shows the correct way to configure include and exclude rules when exclude rules need to be more specific than general include rules. This ensures '/d/e' is included while '/d/f' and '/d/g' are excluded.

```yaml
- path: /d/*
- path: /d/f
  exclude: true
- path: /d/g
  exclude: true
```

--------------------------------

### Apply ApplicationSet CRDs and Build Controller

Source: https://github.com/argoproj/applicationset/blob/master/docs/E2E-Tests.md

Apply the necessary Custom Resource Definitions (CRDs) for ApplicationSet and build the controller. This is a prerequisite for running the ApplicationSet controller and its E2E tests.

```bash
kubectl apply -f manifests/crds/argoproj.io_applicationsets.yaml
make build
```

--------------------------------

### Checkout Master Branch

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Switch to the master branch to prepare for version updates.

```shell
git checkout master
```

--------------------------------

### Matrix Generator with Git and Cluster Generators

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Matrix.md

This snippet demonstrates the configuration of the Matrix generator, using Git and Cluster generators as its children. It's used to deploy applications defined in a Git repository to multiple specified clusters.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-git
spec:
  generators:
    # matrix 'parent' generator
    - matrix:
        generators:
          # git generator, 'child' #1
          - git:
              repoURL: https://github.com/argoproj/applicationset.git
              revision: HEAD
              directories:
                - path: examples/matrix/cluster-addons/*
          # cluster generator, 'child' #2
          - clusters:
              selector:
                matchLabels:
                  argocd.argoproj.io/secret-type: cluster
  template:
    metadata:
      name: '{{path.basename}}-{{name}}'
    spec:
      project: '{{metadata.labels.environment}}'
      source:
        repoURL: https://github.com/argoproj/applicationset.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: '{{server}}'
        namespace: '{{path.basename}}'
```

--------------------------------

### SCM Provider Generator Basic Configuration

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-SCM-Provider.md

Basic configuration for the SCM Provider generator, specifying the clone protocol.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - scmProvider:
      # Which protocol to clone using.
      cloneProtocol: ssh
      # See below for provider specific options.
      github:
        # ...
```

--------------------------------

### SCM Provider Filters Configuration

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-SCM-Provider.md

Use filters to select specific repositories for generation. Filters can match repository names, paths, labels, and branches.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - scmProvider:
      filters:
      # Include any repository starting with "myapp" AND including a Kustomize config AND labeled with "deploy-ok" ...
      - repositoryMatch: ^myapp
        pathsExist: [kubernetes/kustomization.yaml]
        labelMatch: deploy-ok
      # ... OR any repository starting with "otherapp" AND a Helm folder.
      - repositoryMatch: ^otherapp
        pathsExist: [helm]
  template:
  # ...

```

--------------------------------

### Push Release Candidate Image

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Push the built container image to Quay.io using 'make image-push', specifying all necessary image details and registry information.

```bash
IMAGE_NAMESPACE=argoproj IMAGE_NAME=argocd-applicationset IMAGE_TAG=v(version) CONTAINER_REGISTRY=quay.io   make image-push
# Example: IMAGE_NAMESPACE=argocdapplicationset IMAGE_NAME=argocd-applicationset IMAGE_TAG=v0.1.0 CONTAINER_REGISTRY=quay.io   make image-push
```

--------------------------------

### Enable Dry Run Mode for ApplicationSet Controller

Source: https://github.com/argoproj/applicationset/blob/master/docs/Controlling-Resource-Modification.md

To enable dry-run mode, add `--dryrun true` to the ApplicationSet Deployment's container launch parameters. This puts the controller in a read-only mode.

```bash
--dryrun true
```

--------------------------------

### Verify Git Status and Log

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Check the current git status and log to ensure the branch contains the expected commits before proceeding.

```shell
git status
git log
```

--------------------------------

### Create Release Candidate Branch

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Create a new branch for a release candidate, typically named with '-rc' suffix. This is for RC documentation and images, not the final release.

```bash
git checkout -b release-(version)-rc
# example: git checkout -b release-0.1.0-rc
```

--------------------------------

### Bitbucket SCM Provider Configuration

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-SCM-Provider.md

Configure the Bitbucket SCM provider to scan a workspace for repositories. Specify owner, user, and authentication details.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - scmProvider:
      bitbucket:
        # The workspace id (slug).
        owner: "mmerrill"
        # The user to use for basic authentication with an app password.
        user: "mmerrill"
        # If true, scan every branch of every repository. If false, scan only the main branch. Defaults to false.
        allBranches: true
        # Reference to a Secret containing an app password.
        appPasswordRef:
          secretName: appPassword
          key: password
  template:
  # ...

```

--------------------------------

### Helm String Literal for Templates

Source: https://github.com/argoproj/applicationset/blob/master/docs/Template.md

When deploying ApplicationSet resources with Helm, use Helm string literals to prevent errors with templating notation.

```yaml
    metadata:
      name: '{{`{{cluster}}`}}-guestbook'
```

--------------------------------

### Git Directory Generator Output Parameters

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Matrix.md

The output parameters generated by the Git directory generator, identifying discovered application directories and their base names. This is a precursor to the Matrix generator's combination step.

```yaml
- path: /examples/git-generator-directory/cluster-addons/argo-workflows
  path.basename: argo-workflows
  
- path: /examples/git-generator-directory/cluster-addons/prometheus-operator
  path.basename: prometheus-operator
```

--------------------------------

### Basic Pull Request Generator Configuration

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Pull-Request.md

This snippet shows the basic structure for configuring a Pull Request generator within an ApplicationSet.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - pullRequest:
      # See below for provider specific options.
      github:
        # ...

```

--------------------------------

### Tag Release with 'stable'

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Tag the release commit with the 'stable' tag. Perform a dry-run push first to verify the operation, then push the tag upstream.

```shell
# ENSURE you are still on the (RELEASE BRANCH)
# or do `git checkout (TARGET_TAG)`, to ensure you are on the right commit.

# Tag the release commit with the stable tag
git tag -f stable

# Dry-run the tag push, to make sure that nothing bad will happen:
git push upstream -n -f stable

# Now, push the tag upstream"
git push upstream -f stable
```

--------------------------------

### ApplicationSet Template with Pull Request Variables

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Pull-Request.md

Defines the application template using variables from the Pull Request generator, such as PR number, branch, and head SHA.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - pullRequest:
    # ...
  template:
    metadata:
      name: 'myapp-{{branch}}-{{number}}'
    spec:
      source:
        repoURL: 'https://github.com/myorg/myrepo.git'
        targetRevision: '{{head_sha}}'
        path: kubernetes/
        helm:
          parameters:
          - name: "image.tag"
            value: "pull-{{head_sha}}"
      project: default
      destination:
        server: https://kubernetes.default.svc
        namespace: default

```

--------------------------------

### Incorrect Exclude/Include Rule Order

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

Illustrates an incorrect configuration where an exclude rule with a wildcard ('/d/*') takes precedence over an intended include rule ('/d/e'), causing '/d/e' to be excluded.

```yaml
- path: /d/e
  exclude: false
- path: /d/*
  exclude: true
```

--------------------------------

### Shorter Corrected Exclude/Include Rule Order

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

A more concise version of the corrected include/exclude rule configuration using path matching syntax to exclude specific subdirectories ('/d/f' and '/d/g') from a broader include rule ('/d/*').

```yaml
- path: /d/*
- path: /d/[f|g]
  exclude: true
```

--------------------------------

### ConfigMap for Resource Configuration

Source: https://github.com/argoproj/applicationset/blob/master/examples/clusterDecisionResource/README.md

Configures the resource to read status of generated ArgoCD clusters from. This specifies the API version, kind, status list key, and match key.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  apiVersion: group.io/v1
  kind: mykinds
  statusListKey: clusters
  matchKey: name
```

--------------------------------

### Cluster Generator with Label Selector

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Cluster.md

This ApplicationSet configuration uses the Cluster generator with a label selector to target only clusters that have the label 'staging: true'.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  namespace: argocd
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          staging: true
  template:
  # (...)
```

--------------------------------

### Commit Release Changes

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Create a new Git commit with a signed-off message for the release, including changes to manifests, docs, and the .github and hack directories.

```bash
git commit -s -m "Release ${TARGET_TAG}" VERSION manifests/ docs/ .github hack/
```

--------------------------------

### Basic Cluster Generator Usage

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Cluster.md

This ApplicationSet configuration uses the Cluster generator to automatically discover all clusters registered with Argo CD. It uses the 'name' and 'server' fields from the cluster secrets to define the Application's destination.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  namespace: argocd
spec:
  generators:
  - clusters: {} # Automatically use all clusters defined within Argo CD
  template:
    metadata:
      name: '{{name}}-guestbook' # 'name' field of the Secret
    spec:
      project: "default"
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps/
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{server}}' # 'server' field of the secret
        namespace: guestbook
```

--------------------------------

### List Generator Element Forms

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-List.md

Illustrates the evolution of the List generator's element format. The v0.1.0 form required 'cluster' and 'url' keys, while v0.2.0+ supports arbitrary key/value pairs, including the older form.

```yaml
spec:
  generators:
  - list:
    elements:
      # v0.1.0 form - requires cluster/url keys:
      - cluster: engineering-dev
        url: https://kubernetes.default.svc
        values:
          additional: value
      # v0.2.0+ form - does not require cluster/URL keys
      # (but they are still supported).
      - staging: "true"
        gitRepo: https://kubernetes.default.svc   
# (...)

```

--------------------------------

### Commit Version and Manifest Changes

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Commit the updated VERSION file and regenerated manifests after incrementing the version number.

```shell
git commit -s -m "Increment version for next release" VERSION manifests/
```

--------------------------------

### Configure Git Provider Webhook Secrets

Source: https://github.com/argoproj/applicationset/blob/master/docs/Generators-Git.md

Add your Git provider's shared webhook secret to the `stringData` field of the `argocd-secret` Kubernetes secret. This is optional but recommended for security.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
  namespace: argocd
type: Opaque
data:
...

stringData:
  # github webhook secret
  webhook.github.secret: shhhh! it's a github secret

  # gitlab webhook secret
  webhook.gitlab.secret: shhhh! it's a gitlab secret
```

--------------------------------

### Push Release Candidate Branch

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Push the release candidate branch to the origin remote to make the branch available for further actions.

```bash
git push origin release-(version)-rc
# Example: git push origin release-0.1.0-rc
```

--------------------------------

### Push Tagged Commit

Source: https://github.com/argoproj/applicationset/blob/master/docs/Releasing.md

Push the newly tagged commit to the target remote repository. The release.sh script should provide the exact command.

```shell
git push upstream (RELEASE_BRANCH) (TARGET_TAG)
```

--------------------------------

### Edit ApplicationSet Deployment

Source: https://github.com/argoproj/applicationset/blob/master/docs/Controlling-Resource-Modification.md

Use `kubectl edit` to directly modify the running ApplicationSet controller deployment on your cluster. Locate and update the `.spec.template.spec.containers[0].command` field with your desired parameters.

```bash
kubectl edit deployment/argocd-applicationset-controller -n argocd
```

```yaml
spec:
    # (...)
  template:
    # (...)
    spec:
      containers:
      - command:
        - entrypoint.sh
        - applicationset-controller
        # Insert new parameters here, for example:
        # --policy create-only
    # (...)
```