k8s version: 1.28.2
helm version: v3.9.2

I use default values.yaml, and did instructions from docs:

helm repo add convoy https://frain-dev.github.io/helm-charts helm repo update helm install --values values.yaml convoy convoy/convoy -n convoy

But deployments convoy-server and convoy-worker did not started, they are stuck on init containers wait-for-migrate

In logs of wait-for-migrate container I see this logs:
Error from server (NotFound): jobs.batch "convoy-migrate" not found Waiting for migrate job to complete...

Comparing the docker-compose.yml provided in the convoy repo against the cmd and args config for the Stream, Worker, and Server components (child charts), there's a clear difference in configuration. For example, all three components are configured like this in their deployment.yaml templates:

...
  containers:
    - name: convoy-server
      image: docker.cloudsmith.io/convoy/convoy/frain-dev/convoy:v0.9.2
      imagePullPolicy: IfNotPresent
      volumeMounts:
        - name: convoy-config
          mountPath: /config
      command: ["/cmd"]
      args: ["server", "--config", "/config/convoy.json", "-w", "false"]
...

and

...
containers:
  - name: convoy-stream
    image: docker.cloudsmith.io/convoy/convoy/frain-dev/convoy:v0.9.2
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - name: convoy-config
        mountPath: /config
    command: ["/cmd"]
    args: ["server", "--config", "/config/convoy.json", "-w", "false"]
...

Whereas the docker-compose.yml has each component configured like this:

worker:
  image: docker.cloudsmith.io/convoy/convoy/frain-dev/convoy:v0.9.2
  command: ["./cmd", "worker", "--config", "convoy.json"]
...
stream:
  image: docker.cloudsmith.io/convoy/convoy/frain-dev/convoy:v0.9.2
  command: ["./cmd", "stream", "--config", "convoy.json"]
...

The --config value being different aside, there's clearly a difference in what arg each component is running with from my examples taken from the child helm charts - notably in stream's case where it's also being started up with the worker arg.

If the docker-compose.yml is the basis for the cmd and args config for each component, the helm charts should be consistent to that.

Guys, any chance you could merge latest branch and add a ConfigMap which is referenced in the helm chart.

1. main branch is out of date. latest version on branch is 0.8 (not merged, no merge request)
   

2. configmap is missing as referenced in the helm chart
   https://github.com/frain-dev/helm-charts/blob/release-0.8/charts/convoy/templates/deployment.yaml#L30

The scheduler, stream, server, and worker Deployments all error out on start up with this message:

Error: migrate: Pending migrations exist, please run convoy migrate first
time="2023-04-19T18:17:33Z" level=fatal msg="migrate: Pending migrations exist, please run convoy migrate first"
Stream closed EOF for dev/convoy-scheduler-c88dbd5c5-s7k62 (convoy-scheduler)

The migrate Job itself also errors out like so:

2023-04-19T17:53:34.565502246Z stdout F {"level":"fatal","msg":"migration up failed with error: pq: syntax error at or near \"NULLS\" handling 1677078479.sql","time":"2023-04-19 17:53:34"}

This is on a fresh rollout using AWS RDS as the DB backend. I'm happy to close this out and file in the convoy repo if that's a better place for this.

On instances where sign up is set to false, redeploying the helm charts causes sign up to be enabled for a brief moment.

The current practice of using values.yaml's config.dsn attribute to essentially stuff an entire JSON object violates security considerations. The values.postgresql attribute is already structured to build the dsn value, and would cooperate with GitOps tooling like FluxCD's helm-controller where value overrides can be injected from Secret. The current methodology:

1. Forces users to put their DB backend credentials in plaintext - in values.yaml if not using pod local postgres
2. Risks placing sensitive information in the open if following a GitOps model such as FluxCD where that config ends up in SCM

The JSON object for config should be compartmentalized and built via a helper template in templates/_helpers.tpl, which also affords flexibility if an end user does not want to include config like smtp setup - the helper template would simply ignore tacking on that attribute to the built JSON object.

Child charts like migrate do not have templates for Ingress resources, so they should be removed from that child chart's values.yaml. Even if helm simply disregards any declared values with defaults if they are not consumed, this is a bad practice and creates potential confusion for end users in the absence of a readme.md.