Update common #10

Add help and message clarifying that preview has certain limits

With this the preview all should be a lot more complete and useful. Closes: validatedpatterns/common#452

Add clustergroup support to preview target

…name attribute This covers the following case: foobar: name: foo namespace: foo project: foo path: charts/all/foo The preview.sh script is passed the name attribute of the application `foo`. So now we first find the key which corresponds to the attribute name `foo` and then use that when looking up the other attributes like path, etc. Closes: validatedpatterns/multicloud-gitops#351

Fix preview when the application's index name is not the same as the name attribute

Otherwise if we pass a boolean in the extraParametersNested we will get: spec.source.helm.parameters[10].value: Invalid value: "boolean": spec.source.helm.parameters[10].value in body must be of type string: "boolean"

Force strings in extraParametersNested

The reason for this is the following: When changing the repo on the hub (by editing the pattern), the expectation is that the repo change will replicate from the hub to the spokes managed by ACM. Today this is very unlikely to happen because changing the repo on the hub will not change the policy and so ACM will not reapply it on the spokes. (I believe there is like a daily repush that happens even when the policy has not changed, but that is way too slow to be relied upon). By using the actual variable the policy will actually change, ACM will notice this and push the change on the spokes. Found while testing disconnected mode. I am not replacing them everywhere because I am not sure yet if there are additional semantics in common/clustergroup that I am unaware of.

In ACM policies do not use $ARGOCD_APP_SOURCE_* variables

This feature relies on the VP operator version >= 0.0.44 in order to work. The way to enable this is to add a feature flag called 'initcontainers' in the VP operator. Once this is enabled, we will detect this and take over the all ArgoCD instances' definition and add initContainers which will inject the CAs contained in the trusted-bundle-ca configmap and also the openshift internal CA. Testing protocol: 1. (Operator 0.0.44) MCG deployment with experimentalCapabilities set to '' and using a github main upstream (i.e. without this PR) 2. (Operator 0.0.44) MCG deployment with experimentalCapabilities set to 'initcontainers' and using a github diconnected common upstream (requiring a custom CA) (i.e. with this PR) 3. (Operator 0.0.44) MCG deployment with experimentalCapabilities set to '' and using a github diconnected common upstream. (same as 1.2) and then set the initcontainer capability on the hub. Checked that the .global.experimentalCapabilities property replicated from hub to spoke and the initcontainers have been generated correctly 3.1 (Operator 0.0.44) Change the repo from github to an internal one that does need the custom ca to work 4. (Operator 0.0.43) Test an old operator with a newer common that contains this very branch Note: Once we will make initcontainers a default feature of the operator we will remove the ifs added in this PR and just make it the defaut behaviour.

The changes here support the "Support for merging of namespaces, projects, subscriptions and application in overrides/values-common.yaml #459" issue that was opened by Northrop Grumman Files that were changed are: clustergroup/templates/_helpers.tpl clustergroup/templates/core/namespaces.yaml clustergroup/templates/core/operatorgroup.yaml clustergroup/templates/plumbing/projects.yaml clustergroup/values.schema.json examples/values-example.yaml The idea is that if you define the projects section, or the namespaces section, in two different values files using a map construct we will be able to merge both definition of projects into the final rendering of the manifests. The new structure for projects is as follows: ``` clusterGroup: ... projects: project1: ``` The new structure for namespaces is as follows: ``` clusterGroup: ... namespaces: namespace1: open-cluster-management: labels: openshift.io/node-selector: "" kubernetes.io/os: linux annotations: openshift.io/cluster-monitoring: "true" owner: "namespace owner" ``` The user would need to choose to use a list or a hashmap object. The user would not be able to use a mix of hashes and list to describe projects or namespaces.

Not entirely sure how this slipped in. Reported-by: Martin Jackson <[email protected]>

Drop unused piece of schema json

Custom CA support

Small cleanup to remove unneeded log messages

If the clusterwide proxy object is configured, let's support it when we clone the git repos for the imperative framework.

Support for cluster-wide proxy

Update ESO to 0.9.14

feat: Support for issue #459

Update CRD from operator v0.0.44

Expose main.experimentalCapabilities in operator-install

Release clustergroup v0.8.3

Co-authored-by: Alejandro Villegas <[email protected]> Signed-off-by: Tomer Figenblat <[email protected]>

This allows us to have a remote repoURL + path kustomize combo and show the resulting templates in `make preview`. Tested with: web-terminal: name: web-terminal namespace: hello-world project: hub kustomize: true targetRevision: main repoURL: https://github.com/redhat-cop/gitops-catalog path: web-terminal/aggregate/overlays/default Closes: validatedpatterns/multicloud-gitops#356

Support remote repoURL when previewing templates

Co-authored-by: Alejandro Villegas <[email protected]> Signed-off-by: Tomer Figenblat <[email protected]>

- Fixed issue in common/clustergroup/templates/_helpers.tpl to render correct label

Namespace argocd.argoproj.io/managed-by label issue

This corrects Argo error: Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): `helm template . --name-template acm --namespace open-cluster-management --kube-version 1.25 --set global.privateRepo=false --set global.experimentalCapabilities=initcontainers --set global.repoURL=https://github.myrepo.com/EnterpriseKubernetes/multicloud-gitops.git --set global.clusterDomain=mydomain.azure.us --set global.clusterPlatform=Azure --set global.hubClusterDomain=mydomain.azure.us --set global.localClusterDomain=mydomain.azure.us --set global.targetRevision=prod --set global.namespace=open-cluster-management --set global.pattern=ekho --set global.clusterVersion=4.12 --values <path to cached source>/values-global.yaml --values <path to cached source>/values-hub.yaml <api versions removed> --include-crds` failed exit status 1: Error: YAML parse error on acm/templates/policies/application-policies.yaml: error converting YAML to JSON: yaml: line 50: did not find expected key Use --debug flag to render out invalid YAML Also corrects mapping error warning on make preview-acm

This way it can be set straight from a values-*.yaml file Tested on MCG.

Add main.experimentalCapabilities to values.schema.json

ClusterGroup v0.8.4

Moved CLUSTERGROUP declaration to restore make preview-% functionality

This way the code is a bit less confusing and it's more obvious when/where CLUSTERGROUP is used. make preview-% still keeps working as usual and you can override things via `make CLUSTERGROUP=group-one preview-hello-world` Gotta love Makefile's idiosyncrasies around per-target variables

Small makefile tweak

bug: Fixes indenting and duplicate entries in application-policies.yaml

…ion has labels - Added condition to check if operatorGroup key exists {{- if or $v.operatorGroup (not (hasKey $v "operatorGroup")) }} - Default behavior is that we generate an OperatorGroup for a Namespace definition.

Small cleanups

bug: Fix to generate OperatorGroup definition when namespaces definition has labels

Try fallbacks for /etc/pki when it does not exist

- Fixed issue with rendering multiple OperatorGroup. Added the beginning (---) to signal document start. - Updated the applications.yaml to include beginning (---) to signal document start.

helper operatorgroup fix

Update ESO to 0.9.16

Updated vault-helm to v0.28.0

In case a git repo has some things split over submodules, let's clone those too. The version of git in the imperative image is currently: sh-5.1# git version git version 2.39.3 Tested with: sh-5.1# git clone --recurse-submodules --single-branch --branch main --depth 1 -- "https://github.com/validatedpatterns/multicloud-gitops" /tmp/ Cloning into '/tmp'... remote: Enumerating objects: 426, done. remote: Counting objects: 100% (426/426), done. remote: Compressing objects: 100% (343/343), done. remote: Total 426 (delta 87), reused 221 (delta 40), pack-reused 0 Receiving objects: 100% (426/426), 545.98 KiB | 1.78 MiB/s, done. Resolving deltas: 100% (87/87), done. Co-Authored-By: Sergio Garcia Martinez <[email protected]>

Use --recurse-submodules when cloning

The last job we ran with that for IIB was more than 4 months ago.

Improve IIB

Check for prereqs for IIB

…for clusterdeployments Signed-off-by: Tomer Figenblat <[email protected]>

Signed-off-by: Tomer Figenblat <[email protected]>

This adds multiple IIB support in order to cater for the ACM IIB case, where the MCE operator might be in another IIB completely. To load multiple IIB for different operators, one needs to set the env variables as follows: export OPERATOR=advanced-cluster-management,multicluster-engine export INDEX_IMAGES=registry-proxy.engineering.redhat.com/rh-osbs/iib:713808,registry-proxy.engineering.redhat.com/rh-osbs/iib:718034 It is implied that the first IIB is for the first operator in the list, and the second one for the latter. Tested gitops-iib and it all worked with no changes.

Rework IIB loading support

We need to be able to explicitely override the Source and the Channel used to install the MCE multicluster-engine operator. The reason for this is that when we install ACM from an IIB, the default channel that will be used for MCE won't be present in the IIB, so we need to be able to be flexible in determining where the MCE gets installed from (sourcecatalog and channel) We default to redhat-operators because otherwise when installing gitops via IIB the ACM operator finds a channel for MCE that does not exist, so we force the source all the time.

acm iib overrides

Switch to gitops-1.12

Release clustergroup v0.8.5

- Added new section for to configure the ArgoCD server to support tls argocdServer: route: tls: insecureEdgeTerminationPolicy: Redirect termination: reencrypt - Default for ArgoCD is to create route with the following: route: enabled tls: insecureEdgeTerminationPolicy: Redirect termination: passthrough For more information please refer to https://issues.redhat.com/browse/GITOPS-3918. - Changed default value for termination

Improve readme for ACM IIB

New global scope argocdServer section for values-global.yaml

We drive this from the patterns-operator-config configmap these days, which makes more sense (it is a clusterwide setting and not really a per pattern one).

Tested with: ❯ helm template operator-install --show-only templates/subscription.yaml --set main.patternsOperator.installPlanApproval=Manual --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: patterns-operator namespace: openshift-operators labels: operators.coreos.com/patterns-operator.openshift-operators: "" spec: channel: fast installPlanApproval: Manual name: patterns-operator source: community-operators sourceNamespace: openshift-marketplace ❯ helm template operator-install --show-only templates/subscription.yaml --set main.patternsOperator.installPlanApproval=Manual --set main.patternsOperator.startingCSV=1.2.3 --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: patterns-operator namespace: openshift-operators labels: operators.coreos.com/patterns-operator.openshift-operators: "" spec: channel: fast installPlanApproval: Manual name: patterns-operator source: community-operators sourceNamespace: openshift-marketplace startingCSV: 1.2.3

Drop gitopsspec from pattern's CR

Allow customizing the VP operator subscription

Add retries when checking oc version

Add an imperative-admin-sa service account

This makes the registry url more consistent with what we already use (e.g. in the imperative templates)

Switch to registry.redhat.io for the initContainer image

- If statement was checking for .Values.global.extraValueFiles. - We now checking at the .extraValueFiles in the managedClusterGroups section. managedClusterGroups: aro-prod: name: innovation acmlabels: - name: clusterGroup value: innovation extraValueFiles: - '/overrides/values-common-capabilities.yaml' helmOverrides: - name: clusterGroup.isHubCluster value: "false"

Update for ACM chart to application-policies.yaml

- Problem Statement The current **clustergroup** schema does not allow the definition of **extraParameters** under the **main** section of a values file. - Caveat The user defined variables in the **extraParameters** section would only be applied if the user deploys the pattern via the command, using `./pattern.sh make install` or `./pattern.sh make operator-deploy` and not via the OpenShift Validated Patterns Operator UI. - Fix Description Add the **extraParameters** to the definition of **Main.properties** in the values.schema.json: "extraParameters": { "type": "array", "description": "Pass in extra Helm parameters to all ArgoCD Applications and the framework." }, - This will allow users to define extra parameters that will be added by the framework to the ArgoCD applications it creates. - For more information see validatedpatterns/common#510

Add extraParameters to values.schema.json

Update ESO to 0.9.18

…n of a values file. - The operator adds these extraParameters to the extraParametersNested section as key/value pairs in the Cluster Wide ArgoCD Application created by the Validated Patterns operator. - This update will add the user defined extra parameters on the ArgoCD Applications on the Spoke Clusters. efinition of extraParameters under the main

We'd like to make the imperative namespace optional, so let's use the golang-external-secrets one, which is probably more correct anyways since the acm hub ca is tied to ESO anyways.

The acm hub ca is needed for ESO on spokes to connect to the vault on the hub, there is no need for this when vault is not used, so let's drop it in that case

Feat: Followup to definition of extraParameters under the main section of a values file.

Updates to acm-hub-ca

Update vault to 1.16.2

…er-namespace Co-authored-by: Michele Baldessari <[email protected]> Co-authored-by: Alejandro Villegas <[email protected]> Signed-off-by: Tomer Figenblat <[email protected]>

This is important because in some situations (we've observed this on the clusterwide argo instance on spokes) the permissions are not there yet when argo tries to create service accounts for the imperative SAs. This means that the very first sync works up to the service account creation which then fails due to lacking RBACs. This triggers a gitops issue where selfheal never retries because the previous run failed and so the app is in a stuck loop forever Co-Authored-By: Jonny Rickard <[email protected]> Closes: GITOPS-4677

Force rolebindings as early as possible

Problem Statement: When setting a namespace like this: - openshift-distributed-tracing: operatorGroup: true targetNamespaces: [] The chart generates the following yaml: ```yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-distributed-tracing-operator-group namespace: openshift-distributed-tracing spec: targetNamespaces: ``` Which k8s rejects the targetNamespaces key as invalid when it attempts to apply it and removes it since it doesn't have a value, which just so happens to have the desired result of not setting the targetNamespaces (or a selector) to enable it for All Namespaces.

bug: Invalid OperatorGroup generated when omitting targetNamespaces

feat: use hive clusterdeployment for creating spoke clusters

Fix CI issue

…sters Added support to control the scheduler/cluster spec

Simplified PR for auto approve install plans

Actually use adminServiceAccountName for the auto approve job

This should fix the fact that jobs are triggered on unrelated changes

Make sure that the if condition on chart split is not always true

Bump super-linter from 5 to 6

Add some debugging to the chart split action

Otherwise we will get errors during the command as git subtree has regressed since v2.44.0

Use a specific git version when running git subtree split

Release clustergroup v0.8.6

Add sudo to apt-get invocation

Add some READMEs in the individual charts

When setting up vault we loop through all the managed clusters and set up the token so ESO can fetch certain paths in vault. This happens in the unseal vault ansible job and will fail if one of the managed clusters is unreachable. This is undesirable because a cluster might have been shut down on purpose or might be temporarily not reachable and this is no reason to stop the configuration of vault. Tested as follows: 1. Deployed mcg on sno1 and sno2. All green. 2. Shut off sno2 so it is unreachable. observed unseal-cronjob fail (took a while but eventually failed with: ``` TASK [vault_utils : Fetch remote ansible to remote cluster] ******************** ok: [localhost] => (item=local-cluster) An exception occurred during task execution. To see the full traceback, use -vvv. The error was: urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='api.sno2.ocplab.ocp', port=6443): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f1e08dd4670>: Failed to establish a new connection: [Errno 110] Connection timed out')) failed: [localhost] (item=sno2) => {"ansible_loop_var": "item", "changed": false, "item": {"key": "sno2", "value": {"bearerToken": "eyJhbGciOiJSUzI1... ``` 3. Imported sno3 into the hub on sno1. observed unseal-cronjob still fail: ``` TASK [vault_utils : Fetch remote ansible to remote cluster] ******************** ok: [localhost] => (item=local-cluster) An exception occurred during task execution. To see the full traceback, use -vvv. The error was: urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='api.sno2.ocplab.ocp', port=6443): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fb5d293e0a0>: Failed to establish a new connection: [Errno 110] Connection timed out')) failed: [localhost] (item=sno2) => {"ansible_loop_var": "item", "changed": false, "item": {"key": "sno2", "value": {"bearerToken": "ey... ok: [localhost] => (item=sno3) PLAY RECAP ********************************************************************* localhost : ok=37 changed=11 unreachable=0 failed=1 skipped=13 rescued=0 ignored=0 ``` 4. After the ignore_errors patch: ``` TASK [vault_utils : Fetch remote ansible to remote cluster] ******************** ok: [localhost] => (item=local-cluster) An exception occurred during task execution. To see the full traceback, use -vvv. The error was: urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='api.sno2.ocplab.ocp', port=6443): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fc4b7805670>: Failed to establish a new connection: [Errno 110] Connection timed out')) failed: [localhost] (item=sno2) => {"ansible_loop_var": "item", "changed": false, "item": {"key": "sno2", "value": {"bearerToken": "eyJhb.... ok: [localhost] => (item=sno3) ...ignoring # sno2 correctly gets skipped in the subsequent tasks ``` sno3 did manage to login to the vault and everything just worked Reported-by: François Charette <[email protected]>

Skip unreachable spokes when setting up vault

Add no_log to spokes initialization task

This will allow us to work with external CAs out of the box and also it will allow the framework to be able use internal gitea instances out of the box. Tested as follows: 1. Deployed stock MCG with no changes 2. Changed the MCG repo to one with this patch 3. Observed initContainers to show up on: A. namespaced argo on hub B. clusterwide argo on spoke C. namespaced argo on spoke 4. All applications still worked 5. Deployed mcg from scratch using a branch with this patch (with multisource set to false so we're sure we're testing the right common bits in the branch)

Make initContainers the default

Release clustergroup v0.8.7

Upgrade ESO to v0.9.19

It's the version gitops 1.12 is using these days: ❯ oc exec -it -n openshift-gitops openshift-gitops-repo-server-66bf746964-926qk -c argocd-repo-server -- bash -c "helm version" version.BuildInfo{Version:"v3.14.0", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"", GoVersion:"go1.21.9 (Red Hat 1.21.9-1.module+el8.10.0+21671+b35c3b78)"}

Update helm version in CI to 3.14.0

Now that we switched to imperative.initcontainers.gitinit-ca, the older define is not used anywhere, so we can drop this.

Otherwise if HEAD is specified we get the following: mkdir: cannot create directory '/git/home': File exists Cloning into '/git/repo'... warning: Could not find remote branch HEAD to clone. fatal: Remote branch HEAD not found in upstream origin

Make unseal HEAD work

Make healthchecks configurable

Make resourcehealthchecks configurable

Otherwise we might error out with: error: unknown option `branch qe_test-16831' usage: git clone [<options>] [--] <repo> [<dir>]

Do not quote $BRANCH variable

initContainers on the clusterwide argo instances on spokes rely on a configmap called "trusted-ca-bundle" that gets created by ACM in the openshift-gitops namespace. Since we have no explicit guarantees about ordering, it might happen that the argocd object gets created by acm before the configmap. This is problematic because the init container will start but just ignore the missing configmap. Solve this by splitting the ocp-gitops-policy in two and making sure that both the openshift-gitops subscription and the trusted-ca-bundle configmap are green before applying the next dependency.

Fix initcontainer race on spokes

Release clustergroup v0.8.8

configure annotation based resource tracking

With the switch to initcontainers they are not used anywhere anymore

Drop imperative.volumes and imperative.volumemounts

When using a password with a dollar, the oc exec commands run inside the vault are not properly escaped, casing the dollar signed to be interpreted by the shell inside the vault pod. So a password like 'Y$yxn54&qXAxpUd2*yGH' will become 'Y&qXAxpUd2*yGH' in the vault. This is because the command that is being run ends up being: oc exec -n vault vault-0 -i -- sh -c "vault kv patch -mount=secret global/mysecret dollar=Y$yxn54&qXAxpUd2*yGH" The `$yxn54` will be interpreted by the shell inside vault. Let's fix this by running a properly escaped command: oc exec -n vault vault-0 -i -- sh -c "vault kv patch -mount=secret global/mysecret dollar='"'Y$yxn54&qXAxpUd2*yGH'"'" Reported-By: Chris Butler <[email protected]>

With this change we push the hub CA to the spokes in both the openshift-gitops, the namespaced argo namespace and in the imperative namespace. We do this so that the two argo instances are allowed to clone from an eventual gitea repository on the hub. Same goes for the imperative framework which might need to clone the code from the in-cluster gitea service running on the hub.

Support for gitea on spokes

Properly quote vault kv command

Update chart versions

Multisource on spokes

Release clustergroup v0.8.9

Release clustergroup v0.8.10

Release acm v0.0.3

Small multisource fix

Release acm v0.0.4

Update chart versions

Update vault-helm to v0.28.1 and vault to 1.17.2

Update ESO to 0.9.20

Release new hashicorp-vault and golang-external-secrets charts

Provide kubeconfig writer

Added support to label/annotate nodes

Currently we test for the existance of local TLS folder and bind mount them in containers. This does not work correctly when using podman machine, because a the test is running on the host and so we might bind mount the wrong folder. For example: On Mac OSX /etc/pki does not exist on the folder and so we bind mount /etc/ssl even though /etc/pki does exist in the podman machine VM Co-Authored-By: Ákos Erős <[email protected]>

Fix pki bind mount when using podman machine

We introduce the `main.git.repoUpstreamURL` parameter. This can be used to set `originRepo`. When `originRepo` is set, an in-cluster gitea will automatically be spawned. In this case `originRepo` will point to the upstream repository and `targetRepo` will point to the internal in-cluster gitea mirror.

resolves #21 rag-llm-gitops

Allow originRepo to be set via make install and main.git parameters

In 98d4312 (Fix pki bind mount when using podman machine) we erroneously dropped some K8S_* variables. Reported-by: Andrew Beekhof <[email protected]>

Fix vars that were erroneously dropped

We specifically also add helmRepoUrl as it make it more discoverable, but we stay flexible in what we accept so that things can be extended without having to be in lockstep with the operator.

Allow more flexibility with multiSourceConfig schema

Since it can be used to point to an alternative file, let's inject it into the container

Inject VALUES_SECRET env var

Add helmRepoUrl variable

Update letsencrypt to v0.1.1

This is needed on spokes when installing in a disconnected environment

A couple of small updated and new releases

Extend the schema for disconnected

Update clustergroup chart to 0.8.12

Update super-linter to v7

Upgrade ESO to v0.10.0

Upgrade vault to 1.17.3

Release new hashicorp-vault and golang-external-secrets charts

It is supported all the way back to OCP 4.12 Tested on sno hub + spoke successfully

Switch to gitops-1.13

See the README for more details, but TLDR: you can use `secret/pushsecrets` to push secrets from any node to the vault. This secret can then be retrieved from either a different namespace or a different cluster node. Tested this with a pushsecret as follows: ``` apiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: pushsecret namespace: hello-world spec: data: - conversionStrategy: None match: remoteRef: property: baz remoteKey: pushsecrets/testme secretKey: bar deletionPolicy: Delete refreshInterval: 10s secretStoreRefs: - kind: ClusterSecretStore name: vault-backend selector: secret: name: existing-secret updatePolicy: Replace ``` The above takes the property called `baz` of an existing secret called `existing-secret` in the `hello-world` namespace and pushes it to the `secret/pushsecrets/testme` vault path. Suggested-By: Chris Butler <[email protected]> Closes: MBP-641

Add a pushsecrets policy and vault path for ESO syncing

…/github.com/validatedpatterns/common.git main

git-subtree-dir: common git-subtree-mainline: a03f7de git-subtree-split: 5acb722

Update common #10

Update common #10

Commits on Mar 29, 2024

Commits on Apr 8, 2024

Commits on Apr 10, 2024

Commits on Apr 11, 2024

Commits on Apr 12, 2024

Commits on Apr 14, 2024

Commits on Apr 16, 2024

Commits on Apr 17, 2024

Commits on Apr 18, 2024

Commits on Apr 19, 2024

Commits on Apr 22, 2024

Commits on Apr 23, 2024

Commits on Apr 26, 2024

Commits on Apr 30, 2024

Commits on May 2, 2024

Commits on May 3, 2024

Commits on May 6, 2024

Commits on May 9, 2024

Commits on May 13, 2024

Commits on May 14, 2024

Commits on May 15, 2024

Commits on May 17, 2024

Commits on May 27, 2024

Commits on May 28, 2024

Commits on May 30, 2024

Commits on Jun 3, 2024

Commits on Jun 4, 2024

Commits on Jun 6, 2024

Commits on Jun 7, 2024

Commits on Jun 10, 2024

Commits on Jun 11, 2024

Commits on Jun 15, 2024

Commits on Jun 18, 2024

Commits on Jun 19, 2024

Commits on Jun 24, 2024

Commits on Jun 29, 2024

Commits on Jul 9, 2024

Commits on Jul 15, 2024

Commits on Jul 19, 2024

Commits on Jul 26, 2024

Commits on Jul 29, 2024

Commits on Jul 31, 2024

Commits on Aug 6, 2024

Commits on Aug 8, 2024

Commits on Aug 12, 2024

Commits on Aug 13, 2024

Commits on Aug 20, 2024

Commits on Aug 21, 2024

Commits on Aug 22, 2024

Commits on Aug 23, 2024

Commits on Aug 26, 2024

Commits on Aug 27, 2024

Commits on Aug 30, 2024

Commits on Sep 5, 2024