Using this chart if I was to deploy multiple AppSets, I get a warning - in UI and CRD events - that there are multiple applications with the same names.

This is due to the application name always being similar despite deployed via different AppSets.

One solution might be to add suffix of the AppSet name to the application name, this will distinguish the application names and give a visual queue of which service this belongs to.

With the newly release ArgoCD 5.8.x, applicationset spec now supports GitLab pull request.

It would be great if this application supports GitLab merge request similar to GitHub pull request

Add artifacthub docs to chart repo via CI workflow

For unauthenticated GitHub API poll we are getting 403, currently the requeueAfterSeconds is set to 300 (5 minutes), it would better if the default value was set to 500 (8 minutes and 33 seconds). This will reduce number of API requests per hour.

getting error on release:

Error: release name "pr-dependabot-docker-python-3-11-alpine3-17-90-pr-reviews": invalid release name, must match regex ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ and the length must not be longer than 53

Cause:

This is due to ArgoCD application name greater than 53 chars - pattern must be [a-z0-9-].

It would be good if CI workflow was/is able to test helm chart, this would validate if the helm chart is in a good state.

Problem Statement:

On application deployment getting an error on ArgoCD:

Application.argoproj.io "faas-reverse-geocoding-3aa4e21-101-pr-reviews" is invalid: metadata.labels: Invalid value: "dependabot-go_modules-github.com-prometheus-client_golang-1.19.1": must be no more than 63 characters

From the error, application label contains invalid characters.

Proposed Solution(s):

Perhaps we should use sanitised output name similar to branch name in labels.

Please update typo in dynamodb images key - currently it's image and should be images

Problem Statement:

In a continuous deployment environment, there is a need to control the timing of application synchronisations to avoid potential disruptions during peak usage hours. The goal is to establish a sync window in ArgoCD to ensure deployments occur during designated maintenance periods, thereby minimising impact on end-users.

Proposed Solution:

Implement a sync window in ArgoCD to restrict application synchronisations to predefined maintenance periods. This will involve configuring ArgoCD to only allow sync operations during off-peak / working hours, ensuring that deployments do not interfere with critical business operations.

Actions:

• Create ArgoCD Sync Window(s)

Considerations:

• Should have the ability to scope to:
  • namespaces
  • applications
  • projects
  • manual sync
  • schedule
  • clusters

It appears in when application set deletes resources it gets stuck, while some of the resources are deleted/pruned other will infinitely sync/reconcile.

In short, it looks like the finaliser on applicationset template that generates the application is preventing the resources deletion:

Removing that should allow the expected behaviour.

As things stand, the chart will deploy all services to single namespace - declared globally.

I would be better to make the chart flexible and add the ability to to deploy each service to different namespace - if you so with.

We should keep the current behaviour as default, and add an option to override per service.

for example:

repos:
  gitlab:
  - name: service-a
    path: 'deployment/preview'
    project: 13
    namespace: preview # <-- override
    repoUrl: 'https://gitlab.com/project/service-a.git'

Could you couple and parameterise repos and their docker container images. As each repo might have different docker registry, naming and tagging convention.

This would particularly be useful and offer some degree of flexibility to users.

Override global path via repo.path - this allows the ability to set path per repo

Could please add chart lint and/or testing to sanity check PRs