flagsmith / flagsmith-charts

Helm Charts for Flagsmith. Feature flagging and remote config service. Host yourself or use our hosted version.

Flagsmith is an open source, fully featured, Feature Flag and Remote Config service. Use our hosted API, deploy to your own private cloud, or run on-premise.

Flagsmith

Flagsmith makes it easy to create and manage features flags across web, mobile, and server side applications. Just wrap a section of code with a flag, and then use Flagsmith to toggle that feature on or off for different environments, users or user segments.

Get up and running in less than a minute:

curl -o docker-compose.yml https://raw.githubusercontent.com/Flagsmith/flagsmith/main/docker-compose.yml
docker-compose -f docker-compose.yml up

The application will bootstrap an admin user, organisation, and project for you. You'll find a link to set your password in your Compose logs:

Superuser "[email protected]" created successfully.
Please go to the following page and choose a password: https://localhost:8000/password-reset/confirm/.../...

Features

• Feature flags. Release features with confidence through phased roll-outs.
• Remote config. Easily toggle individual features on and off, and make changes without deploying new code.
• A/B and Multivariate Testing. Use segments to run A/B and multivariate tests on new features. With segments, you can also introduce beta programs to get early user feedback.
• Organization Management. Organizations, projects, and roles for team members help keep your deployment organized.
• Integrations. Easily enhance Flagsmith with your favourite tools.

Trying Flagsmith

Flagsmith hosted SaaS

You can try our hosted version for free at https://flagsmith.com/

Flagsmith Open Source

The Flagsmith API is built using Python 3, Django 2, and DjangoRestFramework 3. You can try the application out using:

• Docker
• Kubernetes
• Redhat OpenShift

We also have options for deploying to AWS, GCP, Azure and On-Premise. If you need help getting up and running, please get in touch!

Overview

This repository is formed of 2 core components, the REST API (found in /api) and the web-based administrator dashboard (found in /frontend) that you can use to manage Flagsmith. Technical documentation for each component can be found at the API and Frontend pages within our Documentation

These two components run as separate applications. The web-based dashboard is a single page app that communicates via REST calls to the API.

Resources

• Website
• Documentation
• If you have any questions about our projects you can email [email protected]

Acknowledgements

Thank you to Uffizzi for providing ephemeral environments to preview pull requests.

flagsmith-charts's Issues

Flagsmith charts should set the USE_X_FORWARDED_HOST environment variable if using proxy

USE_X_FORWARDED_HOST should be set to 1 if using the api proxy setting.

Deployed Helm chart but api pod is failing to start... no useful error message to go on:(

Update Postgres

On account of https://artifacthub.io/packages/helm/flagsmith/flagsmith?modal=security-report

gz#285

E2E testing: test with influxdb enabled

Knock-on from #78. Might be low priority, or not wanted at all.

Found that the tests failed when influxdb was enabled. This was the case both locally and in the Github action. Work out why.

See #85

Possibly related to Flagsmith/flagsmith#340

Feature Request: add annotations to Service objects

Hi there! I was wondering if it would be possible to template the annotations applied to the flagsmith-frontend and flagsmith-api Services? We utilize annotations in our set up to work with external DNS, and I'd rather not have to write a script to apply them personally on a new deployment. If it would help, I would gladly submit a PR adding them. Thanks!

segments not working in self-hosted flagsmith

react-dom.production.min.js:187 TypeError: Cannot read properties of null (reading 'find')
at Object.findOperator (utils.tsx:111:23)

Allow setting update strategy on deployments

storageClass

Hi
I cant define specific strorage class for postgreSQL pvc

Deployed helm chart to kubernetes. Api pod fails to start. No error message to work with:(

At deployment time, helm should generate a secretKey value if one is not provided

Linked to Zendesk issue

gz#220

Selfhost without Email

Hi,
i'm currently trying to get Flagsmith up and running inside of our kubernetes cluster.
The Deployment is working just fine, the only issue is, as soon as i try to access a feature flag the configuration window immediately closes.

The logs contain the following error:
django.core.exceptions.ImproperlyConfigured: SENDGRID_API_KEY must be declared in settings.py

In my understanding this settings is required for sending Emails.

According to the documentation https://docs.flagsmith.com/deployment/locally-api#email-environment-variables it should be possible to run Flagsmith selfhosted without email, what Environment Variables need to be set/configured for this to work?

Add ability to use a separate DB connection string for DB migrate and application

So that users can provide different authentication credentials for migrations (where the user needs schema management privileges) and for the application (where the user does not need schema management permissions).

gz#66

Add asynchronous processor to charts

We recently added the asynchronous processor to the stack. This should be added as an optional requirement (which should therefore control the TASK_RUN_METHOD environment variable as required).

Documentation (which could still be improved is here: https://docs.flagsmith.com/deployment/task-processor)

Remove need for duplication between ct.yaml and the release GH action

Both have to know about the chart repos for the chart dependencies, so need to be kept in sync. There might be a nicer way, but helm/chart-releaser#135 suggests maybe not.

Maybe something faintly bonkers like:

yq -r '.chart-repos[]' ct.yaml | sed 's/=/ /' | xargs -L helm repo add

in the release action is OK.

Remove InfluxDB from charts, enable postgres stats by default

Now we can store analytics data in Postgres, there is a good argument for removing InfluxDB entirely from these charts:

• 1 less stateful DB to worry about
• No performance impact to core endpoints
• Simpler chart
• Customers wanting Influx can still set it up outside of this chart

So lets remove Influx entirely.

And set up postgres-backed analytics as the default setup for this chart.

E2E testing: use Chrome instead of (or as well as) Firefox

Knock-on from #78. Might be low priority, or not wanted at all.

Found that Firefox would run in the kind cluster in the Github Action, but Chrome wouldn't. Work out why and use Chrome instead (or as well?).

helm chart 16.0 and 16.1 frontend failing to function properly

Using fluxcd for auto-upgrading the helm chart that deploys to my kubernetes cluster.
With the release of 0.16.0 and 0.16.1, when I try to login to the frontend authentication seems to be getting attempted at https://api-staging.flagsmith.com instead of my local exposed api endpoint. Rolling back to 0.15.0 of the chart restores the functionality of the frontend.

I did not know if this was an error in the helm chart or in the build of the container for frontend explicitly. I decided to post here first in case it was an environment variable issue that was missed while incorporating the latest frontend to the helm charts.

Configure Environment ENV prod

I installed the flagsmith in kubernetes and have everything working, but when i access the url it show in the butterbar the message " You are using the develop environment. "

I configure the Extraenv : DEV: 'prod' and during helm install i set debug and it shows the Environment variable is being created, but the message don't disappear.

Can anyone help me what i need to do to remove this message?

Support for injection of extra containers

We'd like to pull metrics from our flagsmith instance. We use prometheus internally which, as far as I know, flagsmith does not natively support via scrape endpoints. Flagsmith does support StatsD, however - https://docs.flagsmith.com/deployment/hosting/locally-api#statsd-integration

So, what I'd like to do is run https://github.com/prometheus/statsd_exporter - this can act like a StatsD server, and expose prometheus style metrics. The recommended way to run this is as a sidecar - so the flagsmith STATSD_HOST api env var would be configured as localhost.

Unfortunately with the current helm charts, there is no way to inject additional containers (that I can see, at least). I've seen other helm charts support extraContainers and extraInitContainers - I'm curious if there might be a possibility to add support for these here?

Update InfluxDB

Had a report from a customer that the current version of Influx isn't compatiable with latest version of Kubernetes. Not sure quite how to reproduce however. Can we try and run the chart with Influx enabled and see what happens?

configuring saml SSO via env variables

Hello!

Is it possible to configure SAML SSO only using environment variables?

Frontend Ingress allows for path configuration but only root path is supported

I used the helmchart values to specify the ingress for the frontend as follows:

ingress:
  frontend:
    enabled: true
    annotations: 
      nginx.ingress.kubernetes.io/rewrite-target: /$2
    ingressClassName: ingress
    hosts:
      - host: '*.[MY-DOMAIN]'
        paths: 
        -  /flagsmith(/|$)(.*)
    tls: []
    #  - secretName: chart-example-tls
    #    hosts:
    #      - chart-example.local
  api:
    enabled: false
    annotations: {}
    ingressClassName: null
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
    hosts:
      - host: chart-example.local
        paths: []
    tls: []
    #  - secretName: chart-example-tls
    #    hosts:
    #      - chart-example.local

This results in DOM errors when trying to navigate to my flagsmith instance. The frontend code attempts to load all resources from the root (/) path instead of the path specified by the ingress frontend.

I reached out via discord to see about configuring the frontend to hit the subfolder instead of the root and was told this is not supported. The Flagsmith frontend is indeed hosted at the path I specified, but is not functional because none of the files are found where the index is looking for them. If I manually take the url of any of the resources index is referencing and I insert the subfolder into the url, the file loads appropriately so I know the ingress is working.

The documentation needs to be updated and the helmcharts should be updated to not support any path specification until subfolders are supported for the frontend.

Hardcoding paths for API server may be unnecessary

Hi there 👋 ,

There was recently in #138, as I understand it, an issue that had to do with the path specification being ignored on the front-end code. This was addressed in #139. However, there was no indication in the issue that the same problem was true for the API server, but that was also changed in the fix.

I bring this up because previously we were using NGINX rewrite rules for our path in the API server, but when we tried to upgrade to v0.20.0, we got the following:

Error: release flagsmith failed, and has been uninstalled due to atomic being set: Ingress.extensions "flagsmith-api" is invalid: spec.rules[0].host: Invalid value: "map[host: paths:[/flagsmith/(.)]]": a wildcard DNS-1123 subdomain must start with '.', followed by a valid DNS subdomain, which must consist of lower case alphanumeric characters, '-' or '.' and end with an alphanumeric character (e.g. '.example.com', regex used for validation is '*.a-z0-9?(.a-z0-9?)')

As you can see, we use /flagsmith/(.*) as part of our rewrite, but that no longer works. We can still deploy on v0.18.0, which leads me to think it was this fix that broke it (since that was the last version before the fix). Is there a reason I'm missing that the API ingress was changed as well? And if it was an accident could we open up a PR that reverts it (just for the API server, not the front-end code). Thank you!

Api only deployment

flagsmith-charts/charts/flagsmith/values.yaml

Line 56 in 354101c

enabled: true

It turns out this doesn't work. There is no api only deployment

Incorrect PGBOUNCER secret password parsing

Hi, thanks for maintaining this project.
We encountered problem while testing PgBouncer.

flagsmith-charts/charts/flagsmith/templates/secrets-pgbouncer.yaml

Line 14 in 0cf9120

{{- $urlParts := (include "flagsmith.api.realDatabaseUrl" . | trim | urlParse) }}

secrets-pgbouncer.yaml parses databaseUrl using urlParse to get host, database, user, password seperately.
but urlParse escapes url and results in incorrect password configuration
if there is databaseUrl like postgresql://{user}:password!123@{host}:{port}/{database_name}
This url transformed in secrete as password%21(base64 decoded) such as url escaped string
Other special characters could make error at urlParse

feature request: Add ingressClassName to ingress

In the latest nginx-ingress-controller, it requires ingressClassName to work.

Could you guys add ingressClassName?

Thanks

Upgrade the chart to support the latest version of Flagsmith

First, I would like to express my gratitude for the efforts of the maintainers.

My company needed feature flag functionality, so I was weighing between flipt.io and Flagsmith and ended up self-hosting Flagsmith on our company's k8s.

However, there were unresolved minor bugs and structural issues that couldn't be solved by simply changing the image tag version to the latest, and it was significantly behind the latest version of Flagsmith.

I waited for the Flagsmith chart to be upgraded, but in the meantime, the direction shifted towards using flipt.io in my team, and I ended up being someone who made the team wait in vain without contributing anything. Unfortunately, this means Flagsmith missed a potential user. Perhaps if Flagsmith had been adopted, it could have been widely promoted, which is a bit regrettable.

Please upgrade the chart quickly going forward.

Update Front end ENV vars as per https://github.com/Flagsmith/flagsmith/pull/297

Flagsmith/flagsmith#297

Port is malformed in secret using databaseExternal.port

When bringing your own database for the api server and setting the fields individually, the databaseExternal.port value ends up malformed in the secret. For example, this configuration:

databaseExternal:
  enabled: true
  type: postgres
  host: mypostgreshost.com
  database: postgres
  username: postgres
  password: pgpass
  port: 5432

Is encoded in the secret thusly:

postgres://postgres:[email protected]:%!s(float64=5432)/postgres

This is true even if you don't specify the port field so that it defaults to 5432. However, quoting the value (i.e. port: "5432") will result in the correct connection string. I believe this is because in the helper template, the verb being used is %s whereas maybe %d would be more appropriate. Alternatively, it could be quoted in the template.

While putting the port in quotes isn't a big deal, the current documentation shows it unquoted, and hence the confusion. That said, perhaps there's something on my end that I'm missing and am configuring it incorrectly. Thanks for the chart/product!

Migrate command needs updating

This PR needs accommodating: Flagsmith/flagsmith#680

Support for ExtraVolumes and VolumeMounts

What's missing

• The current helm chart doesn't support ExtraVolumes and ExtraVolumeMounts.
• Condition to check DATABASE_URL is required

Why this is needed

• To fetch external database credentials stored as secrets in the Azure key vault, It's required to mount secrets to the container filesystem.
• If DATABASE_URL is not used, Env vars should be used for DB connection

Reinstate E2E tests in CI

Verified broken (brittle) in #98. Removed in #99.

Fix them and reinstate.

wait-for-db init container waits for local postgres database, even when postgres: enabled: false

My API container is in a CrashLoopBackOff when I use this chart to deploy with an external postgres DB.

The values in my helm config include:

    postgresql:
      enabled: false
    databaseExternal:
      enabled: true
      type: postgres
      host: redacted.us-east-1.rds.amazonaws.com
      port: "5432"
      database: flagsmith
      username: postgres
      password: REDACTED

$ k get pods
NAME                             READY   STATUS                  RESTARTS   AGE
flagsmith-7cf74cb7cf-ccv4x       1/1     Running                 0          2m
flagsmith-api-6c9959c65c-4n49k   0/1     Init:CrashLoopBackOff   2          2m
flagsmith-influxdb-0             1/1     Running                 0          2m

$ k logs flagsmith-api-6c9959c65c-4n49k -c wait-for-db 
wait-for-it.sh: waiting 30 seconds for flagsmith-flagsmith-postgresql.flagsmith.svc.cluster.local:5432
wait-for-it.sh: timeout occurred after waiting 30 seconds for flagsmith-flagsmith-postgresql.flagsmith.svc.cluster.local:5432

When I set postgresql: enabled: true the api launches and properly connects to my configured DB.

chart forces svc.cluster.local in service names

I have deployed my cluster with a custom domain. This results in svc.example.com as my root for all of my services, meaning that the current default deployed cluster, which uses svc.cluster.local can not boot the api pods.

Flagsmith charts should set DJANGO_SECRET_KEY environment variable

Ideally this should be autogenerated when the deployment is created and shared between each node in the api cluster.

Documentation on the django SECRET_KEY variable can be found here:

https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/#secret-key

Allow setting `DJANGO_SECRET_KEY` from an existing secret

This can be done with backwards compatibility with this in _api_environment.yaml:

- name: DJANGO_SECRET_KEY
  valueFrom:
    secretKeyRef:
      {{- if .Values.api.secretKeyFromExistingSecret.enabled }}
      name: {{ .Values.api.secretKeyFromExistingSecret.name }}
      key: {{ .Values.api.secretKeyFromExistingSecret.key }}
      {{- else }}
      name: {{ template "flagsmith.fullname" . }}
      key: DJANGO_SECRET_KEY
      {{- end }}

and this in values.yaml:

api:
  ...
  secretKey: null
  secretKeyFromExistingSecret:
    enabled: false
    name: null
    key: null

Document new secret key options

As per PR here

Seed admin user on deploy

Add a REST POST endpoint that achieves the same functionality as /api/v1/users/config/init/ after deployment. This will make it easier to automate deployments.

E2E testing: specific Docker image

To allow my "monster" to rest in peace (see #78), should replace it with a "e2e-testing" image that is produced alongside the tagged releases. So, for eg, version for 1.2.3 there would also be a 1.2.3 e2e-testing image. (This could live in the same Docker Hub repository, or in a separate one, I don't think it matters.)

Ideally it would:

• have both firefox and chrome installed (see #87)
• have the real (non-bundled) frontend codebase and dependencies and node/npm versions, sufficient to run the tests
• allow easy configuration of the things the horrible code in #78 does with sed:
  • setting concurrency
  • setting which browser to use (firefox and/or chrome)
  • turn off the video* options (I tried turning these off, because I suspect they meant more CPU was getting used, which is in short supply, but this is just a hunch. But certainly, we never retrieve the videos anyway.)
  • an easier and more reliable way of setting the name for the E2E_TEST_TOKEN_[environment] env var. I got a bit confused about what was going on here, tbh.

Include Postgres-backed analytics in default deployment

The default helm chart should run with postgres backed analytics by default.

Add periodic LDAP group / users sync

In the flagsmith application we have written a django management command that synchronises LDAP groups / users with Flagsmith groups / users. This can be run via python manage.py sync_ldap_users_and_groups. We'd like a process for enterprise users to run this on a specific schedule.

My immediate suggestion is to use k8s cron jobs, something like the following.

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "0 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: ldap-sync
            image: flagsmith:${{ api.version }}
            imagePullPolicy: IfNotPresent
            command:
            - python
            - manage.py
            - sync_ldap_users_and_groups
          restartPolicy: OnFailure

However, there are perhaps some additional complications here (I think we might need to add it to the run-docker.sh bash script for example? There might also be a simpler / better way to achieve this.

gz#262

Using K8s helm chart in google cloud platform with cloud sql, keeps on giving error database not ready for connections

Summary

We have our infrastructure in Google cloud Kubernetes.
While trying to setup flagsmith in GCP, I keep on getting this error and the api pod remain in CrashLoopBackOff

core.management.commands.waitfordb WARNING Database not yet ready for connections.

Following is the details of my setup:-

• Using the latest version of helmchart present here, i.e. 0.20.0
• Using Google Cloud SQL(database external) instead of local Postgresql
• Have taskprocessor enabled

After deploying the chart with required values, I keep on getting the above error for api pod
Below is the values.yaml file

    api:
      image:
        repository: flagsmith/flagsmith-api
        tag: 2.57.0
        imagePullPolicy: IfNotPresent
        imagePullSecrets: []
      separateApiAndFrontend: true
      replicacount: 2
      deploymentStrategy: null
      podAnnotations: {}
      resources:
        limits:
          cpu: "1"
          memory: 2Gi
        requests:
          cpu: 500m
          memory: 1Gi
      podLabels: {}
      secretKeyFromExistingSecret:
        enabled: true
        name: flagsmith-credentials
        key: django_secret_key
      nodeSelector: {}
      tolerations: []
      affinity: {}
      podSecurityContext: {}
      defaultPodSecurityContext:
        enabled: true
      livenessProbe:
        path: /health
        failureThreshold: 5
        initialDelaySeconds: 5
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 2
      readinessProbe:
        path: /health
        failureThreshold: 10
        initialDelaySeconds: 1
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 2
      statsd:
        enabled: false
      influxdbSetup:
        enabled: false

    frontend:
      enabled: true
      image:
        repository: flagsmith/flagsmith-frontend
        tag: 2.57.0
        imagePullPolicy: IfNotPresent
        imagePullSecrets: []
      replicacount: 1
      deploymentStrategy: null
      resources:
        limits:
          cpu: 500m
          memory: 500Mi
        requests:
          cpu: 300m
          memory: 300Mi
      apiProxy:
        enabled: true
      extraEnv:
        FLAGSMITH_API_URL: 'https://flagsmith.domain/api/v1/'
      extraEnvFromSecret: {}
      nodeSelector: {}
      tolerations: []
      affinity: {}
      podSecurityContext: {}
      defaultPodSecurityContext:
        enabled: true
      livenessProbe:
        failureThreshold: 20
        initialDelaySeconds: 20
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 10
      readinessProbe:
        failureThreshold: 20
        initialDelaySeconds: 20
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 10

# See https://docs.flagsmith.com/deployment/task-processor
# uses the same image as api but with different entrypoint
    taskProcessor:
      enabled: true
      livenessProbe:
        failureThreshold: 5
        initialDelaySeconds: 5
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 2
      readinessProbe:
        failureThreshold: 10
        initialDelaySeconds: 1
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 2
      podAnnotations: {}
      resources:
        limits:
          cpu: 500m
          memory: 500Mi
        requests:
          cpu: 300m
          memory: 300Mi
      podLabels: {}
      nodeSelector: {}
      tolerations: []
      affinity: {}
      podSecurityContext: {}
      defaultPodSecurityContext:
        enabled: true

    influxdb2:
      enabled: false

    postgresql:
      enabled: false

    databaseExternal:
      enabled: true
      url: postgresql://dbproxy:5432/flagsmith
      type: postgres
      host: dbproxy
      port: 5432
      database: flagsmith
      username: flagsmith
      password:
        valueFrom:
          secretKeyRef:
            key: db_password
            name: flagsmith-credentials
      urlFromExistingSecret:
        enabled: false
        name: null
        key: null

    service:
      api:
        type: ClusterIP
        port: 8000
        annotations: {}
      frontend:
        type: ClusterIP
        port: 8080
        annotations: {}

    ingress:
      frontend:
        enabled: true
        annotations: {}
        ingressClassName: null
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
        hosts:
          - host: flagsmith.domain.dev
            paths:
              - /
        tls: []
      api:
        enabled: true
        annotations: {}
        ingressClassName: null
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
        hosts:
          - host: flagsmith.domain.dev
            paths:
              - /api/
              - /health/
        tls: []

When using a cluster with a custom domain and proxy forwarding, the frontend proxies requests to an inexistent address

As an example, for a cluster with a custom domain of my.cluster.local, the current implementation would proxy requests to

http://flagsmith-api.mynamespace.svc.cluster.local:8000

whereas

http://flagsmith-api.mynamespace.svc.my.cluster.local:8000

would be correct.

This is addressed in PR #61

Wait for it image not compatible with OpenShift

The image used for wait-for-it is not compatible with OpenShift as the script has 711 mode. Creating our own Dockerfile from the wait-for-it base image should work. Something like this:

FROM docker.io/willwill/wait-for-it
RUN chmod 755 /wait-for-it.sh

Allow setting no value for replicas on deployments

(I initially assumed that we did have HPAs in the chart, but there are none atm, so rather than being conditional on whether HPAs are enabled, just make it so there is a way of setting no value for replicas.)

Ability to add labels and annotations to all resources in helm chart

It would be very helpful to expose a configuration for commonLabels and commonAnnotations in the helm chart so users can set labels and annotations on all resources created by the helm chart in one place.

We currently have some integration use-cases that require certain labels/annotations exist on all resources associated with a helm chart, and the pattern above is quite common for other helm charts in the k8s ecosystem.

We'd be happy to put in the PR ourselves if the maintainers agree with the pattern above.

Thanks!

Flagsmith-on-Flagsmith not working when self-hosting

Hi there,

Just had a question about setting up Flagsmith-on-Flagsmith. It seems that even though I have set up both the FLAGSMITH_ON_FLAGSMITH_API_URL and FLAGSMITH_ON_FLAGSMITH_API_KEY variables correctly (verified both by inspecting the k8s Pods as well as in the console), every request to the API server for /flags or /flags/analytics just hangs. When I first open up the front-end app I can still log in, make changes, etc., but none of the custom features I want are coming back (e.g. when calling flagsmith.getValue('oauth_google') I just get null instead of the expected string). After a few hard refreshes there's nothing but the spinning loading modal.

If I remove the relevant environment variables, then everything works, but then we can't run Flagsmith-on-Flagsmith.

Any ideas of what could be going on and why the requests are just hanging? The only logs I'm getting from the API server is app.views WARNING FE assets do not exist, ignoring and returning HTTP 200.. The result is the same when I try to curl it as well.

Extra frontend environment variables:

• API_URL: <api_url>/api/v1/
• FLAGSMITH_API_URL: <api_url>/api/v1/
• FLAGSMITH_ON_FLAGSMITH_API_URL: <api_url>/api/v1/
• FLAGSMITH_ON_FLAGHSMITH_API_KEY: key_from_project
• ENABLE_INFLUXDB_FEATURES: 0

Extra backend environment variables:

• LOG_LEVEL: DEBUG (this is in our dev environment)
• DJANGO_CSRF_TRUSTED_ORIGINS: <origin_our_dashboard_is_under>

Thank you!

Single container Helm chart

Default to the unified docker image

Incorrect field definition in charts/flagsmith/templates/ingress-frontend.yaml

frontendVersion should be defined as apiVersion

diff --git a/charts/flagsmith/templates/ingress-frontend.yaml b/charts/flagsmith/templates/ingress-frontend.yaml
index 87424b4..61530d6 100644
--- a/charts/flagsmith/templates/ingress-frontend.yaml
+++ b/charts/flagsmith/templates/ingress-frontend.yaml
@@ -5,9 +5,9 @@
 apiVersion: networking.k8s.io/v1
 {{- else -}}
 {{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
-frontendVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 {{- else -}}
-frontendVersion: extensions/v1beta1
+apiVersion: extensions/v1beta1
 {{- end }}
 {{- end }}
 kind: Ingress

Add some testing around the Github Action

We should be implementing some targets as part of helm test that are run by ct install