What's the best way to incorporate secrets into this helm chart / manifests? I'm new to k8s but typically I reference them in ENV variables. As homepage has many API keys and urls, it feels prudent to use secrets. Would be great to see an example, thanks in advance.

@jameswynn

Trying to find the right way to make homepage use http_proxy and https_proxy variables, because for whatever reason it seems to ignore both HOMEPAGE_VAR_HTTP/S_PROXY and HTTP/S_PROXY formats. I used the unofficial helm charts to install homepage on a kubernetes cluster and it won't be able to access the web unless the connection is proxied. This is so homepage can get the icons for widgets/services ..

I tried passing the variable in my values.yaml:

env:
  HOMEPAGE_VAR_HTTP_PROXY:
    valueFrom:
      secretKeyRef:
        name: <secret where I stored http proxy variable value>
        key:  secret key>
  HTTP_PROXY:
    valueFrom:
      secretKeyRef:
        name: <secret where I stored http proxy variable value>
        key:  <secret key>

I can see the variable exists inside my container but still no icons.
any ideas?

Is there a way to update this to the latest version of homepage sorry?

Hello there,

I just deployed your helm-chart and it fails to start: MountVolume.SetUp failed for volume "homepage-config" : configmap "dashboard" not found. The configmap is called dashboard-homepage.

Argo app:

project: default
source:
  repoURL: 'https://jameswynn.github.io/helm-charts'
  targetRevision: 1.2.3
  helm:
    parameters:
      - name: ingress.main.enabled
        value: 'true'
      - name: serviceAccount.create
        value: 'true'
      - name: config.kubernetes.mode
        value: cluster
      - name: enableRbac
        value: 'true'
  chart: homepage
destination:
  namespace: dashboard
  name: in-cluster
syncPolicy:
  syncOptions:
    - CreateNamespace=true

Until there is an official helm repo for Homepage, it would be awesome if this unofficial repo could automatically bump versions to stay in sync with the latest upstream Homepage version.

Love the work you've done - again huge thank you @jameswynn !

Pods "homepage-77cdf87bbc-" is forbidden: error looking up service account default/homepage: serviceaccount "homepage" not found:Deployment does not have minimum availability.

Having this line in Helm config:

# The service account is necessary to allow discovery of other services
serviceAccount:
  create: true
  name: homepage

Results in different serviceaccount being created:

qbus@DESKTOP-CA07ILV:~$ kubectl get serviceaccount -n app-homepage
NAME      SECRETS   AGE
default   0         37s
qbus@DESKTOP-CA07ILV:~$

This results in problem because pod is complaining about missing serviceaccount for autodiscovery:

pods "homepage-645f585975-" is forbidden: error looking up service account app-homepage/homepage: serviceaccount "homepage" not found

For completeness, here's my ArgoCD resource I'm using for deployment:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: homepage
  namespace: argocd
spec:
  project: default
  source:
    chart: homepage
    repoURL: https://jameswynn.github.io/helm-charts
    targetRevision: 1.2.3
    helm:
      # releaseName: prometheus-community
      # https://github.com/dotdc/grafana-dashboards-kubernetes
      valueFiles:
        - values.yaml

  destination:
    server: 'https://kubernetes.default.svc'
    namespace: app-homepage
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      selfHeal: true
      prune: true

How I get it is, that chart should create service account of homepage but created default instead.

It would be good, if extra rbac role can be added to ClusterRole

Do you actually get this to work with the config in a configMap?
I'm using my own manifests but I templated your chart and they match.

k logs homepage-7766449f6b-hkmzt
chown: /app/config/kubernetes.yaml: Read-only file system
chown: /app/config/docker.yaml: Read-only file system
chown: /app/config/services.yaml: Read-only file system
chown: /app/config/..data: Read-only file system
chown: /app/config/widgets.yaml: Read-only file system
chown: /app/config/settings.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031/kubernetes.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031/docker.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031/services.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031/widgets.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031/settings.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031/bookmarks.yaml: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031: Read-only file system
chown: /app/config/..2023_04_18_14_06_38.726287031: Read-only file system
chown: /app/config/bookmarks.yaml: Read-only file system
chown: /app/config: Read-only file system
chown: /app/config: Read-only file system

Edit: Ok it's because I specified P/GUID=1000 and it works fine without. The files are root:node but I set securityContext.fsGroup: 1000.

I believe the change in #16 may have broken the ability to update the ConfigMap.

Whenever I update the ConfigMap the change to the ConfigMap works, but it is not reflected in the pod, even after deleting the pod and deployment and recreating them.

Based on what I read here it seems that when subPath is used the ConfigMap data will be pulled from the kubelet cache. If this is correct that would explain why updates are not affecting the deployment/pod.

I am using ArgoCD to deploy Homepage (not sure if that makes a difference or not)