support --access-token-path so that tokens are not in cleartext

[earl-warren]

As it currently stands, the token must be provided in the config file in cleartext

helm-charts/charts/draupnir/values.yaml

Line 119 in 57a29f5

accessToken: "YOUR_TOKEN_HERE"

it would be better to support --access-token-path instead so that it can be obtained from a file mounted from a k8s secrets instead.

https://the-draupnir-project.github.io/draupnir-documentation/bot/starting_draupnir#secret-management

Workaround for flux

When using flux, there is a convenient workaround for which an example is available which is deployed in the Forgejo chatrooms.

[MTRNord]

Oops yeah. There is also a but more work to do to finish this up :) i just got side tracked. But thabk you for mentioning so i wont forget!

[earl-warren]

I'm willing to propose a pull request to fix this. Unless it is too early stages for such a contribution. Maybe you're actively working on it at the moment.

Please let me know: I can set aside time tomorrow to work on that.

[MTRNord]

I am trying to get around to it on the weekend but no hard promises, so I take the PR if you want to :)

The only thing I am currently still working on is an appservice ready variant of the chart, but that shouldn't conflict :)

Just a warning that while I technically use the CI already elsewhere it might fail since I didnt test it in this repo. So in case it does dont worry :)

[earl-warren]

Great to know, I'll work on it tomorrow.

FYI the goal is to use this chart as part of the https://forgejo.org/ infrastructure which is at https://codeberg.org/forgejo/k8s-cluster/. The alternative would be to create a local chart similar to a few others https://codeberg.org/forgejo/k8s-cluster/src/branch/main/flux/apps/charts

But contributing to your early effort seems to be a better choice than accumulating technical debt.

[earl-warren]

I started implementing the needful but I think there actually is a simpler way to do the same, only it needs to be documented (I forgot about that possibility) . Assuming a secret is created as follows:

apiVersion: v1
kind: Secret
metadata:
  name: draupnir-token
type: Opaque
stringData:
  values.yaml: |
    config:
       accessToken: "YOUR_TOKEN_HERE"

It can then be used with valuesFrom

# https://fluxcd.io/flux/components/helm/helmreleases/
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: drap
spec:
 ...
  # https://fluxcd.io/flux/components/helm/helmreleases/#values-references
  valuesFrom:
    - kind: Secret
      name: draupnir-token
  values:
   ...

and it will be merged into one config file.

The arguments are needed when invoking draupnir with a static config file. In the context of flux, the config file is composed dynamically and there is no need for such arguments.