Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

Chart 3.0.0

Description

The chart creates an invalid networking.k8s.io/v1 Ingress, as it attempts to create an ingress with serviceName and servicePort attributes, rather than the correct service.name and service.port.[name|number] attributes.

Expectation

Successful deployment of a networking.k8s.io/v1 Ingress.

Reproduction steps

No response

Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

1.8.2

Description

I wanted to use the yourls.extraConfigContent option, but it seems that the helm templates do not use it. I'm not sure if it was available before or if it's an error.

This is the line I'm referring to:

Expectation

I think this is a broken feature, as there is no code in the helm templates

Reproduction steps

1. Create a values.yaml file
2. Set the yourls.extraConfigContent variable
3. Deploy yourls
4. Access the container and verify the content with cat user/config.php
5. The file won't include the extraConfigContent

Context

The file "user/config.php" should include the content of the variable yourls.extraConfigContent

This issue provides visibility into Renovate updates and their statuses. Learn more

This repository currently has no open or pending branches.

• Check this box to trigger a request for Renovate to run again on this repository

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

Chart 2.2.21

Description

After the addition of .Values.service.port customisation in the Ingress template, values files from 2.2.0 no longer work:

{
  "level": "error",
  "ts": "2021-09-23T10:09:46.143Z",
  "logger": "controller.helmrelease",
  "msg": "Reconciler error",
  "reconciler group": "helm.toolkit.fluxcd.io",
  "reconciler kind": "HelmRelease",
  "name": "yourls",
  "namespace": "gosubme",
  "error": "Helm upgrade failed: template: yourls/templates/ingress.yaml:27:26: executing \"yourls/templates/ingress.yaml\" at <.Values.service.port>: nil pointer evaluating interface {}.service"
}

As yet unsure whether the same issue applies with manually-deployed Helm charts, though I suspect as much.

Expectation

Ingress to be created with servicePort: 80 as there's no override.

Reproduction steps

Deploy a Helm resource with the following values:

service:
  type: ClusterIP
ingress:
  enabled: true
  hosts:
    - name: examplesite.tld
      path: /
      tls: true
      tlsSecret: examplesite-tld-tls

Context

Deployed with the GitOps Toolkit (aka Flux v2). Working fine with chart version 2.2.0.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps and frequent issues guides.

Version

1.9.2

Description

Hi,

I would like to report an error on metrics exporter configuration embedded with the chart.

When we use the Helm chart and set metrics in metrics.enabled on true.
The exporter can't fetch Apache2 status page and returned following error logs:

"Error scraping apache:" err="error scraping apache: Get \"http://status.localhost:8080/server-status/?auto\": dial tcp 127.0.0.1:8080: connect: connection refused"

I have tried to curl the host inside the YOURLS container and I have the same result.
In Apache configuration I can't find a reference about port 8080.

Thanks in advance for your support and I stay available if you need any more precision.

Expectation

We would like to have Apache metrics return without error of the exporter.

Currently we have apache_up metrics in Prometheus with 0 value.

But YOURLS working fine.

Basically, the result should be 1.

Reproduction steps

I use the following values with the chart:

nameOverride: "yourls"
fullnameOverride: "yourls"

image:
  tag: 1.9.2

yourls:
  domain: url.com
  scheme: https
  existingSecret: "yourls-admin"
  tablePrefix: yourls_
  skipInstall: false

extraEnvVarsSecret: yourls

replicaCount: 2
resources:
  limits:
    memory: 512Mi
  requests:
    memory: 512Mi

service:
  type: ClusterIP

ingress:
  enabled: true
  ingressClassName: nginx-public
  hostname: url.com
  path: /
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  tls: true
  extraTls: []

persistence:
  enabled: false

metrics:
  enabled: true
  serviceMonitor:
    enabled: true

mariadb:
  enabled: false

podAntiAffinityPreset: hard

externalDatabase:
  host: "34.140.67.101"
  port: 3306
  user: urlshort
  database: yourls
  existingSecret: "yourls-db"

I'm working with GKE on version 1.24.

Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

1.8.2

Description

Upgrading from the latest 3.x.y release to 4.0.4 fails, with the following messages from Helm:

Last Helm logs:

preparing upgrade for yourls
resetting values to the chart's original version
  Normal  error  67s (x8 over 71s)  helm-controller  reconciliation failed: Helm upgrade failed: execution error at (yourls/templates/NOTES.txt:107:4): 
PASSWORDS ERROR: You must provide your current passwords when upgrading the release.
                 Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims.
                 Further information can be obtained at https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues/#credential-errors-while-upgrading-chart-releases

    'yourls.password' must not be empty, please add '--set yourls.password=$YOURLS_PASSWORD' to the command. To get the current value:

        export YOURLS_PASSWORD=$(kubectl get secret --namespace "gosubme" yourls -o jsonpath="{.data.yourls-password}" | base64 --decode)
  Normal  info  66s (x9 over 71s)  helm-controller  Helm upgrade has started

There's also no documentation in the repository to state that this is needed - it's only in the NOTES.txt file.

Expectation

Helm upgrade should succeed without needing the secret to be specified in plaintext, as there's a mechanism to fetch the value from secrets.

Reproduction steps

Install 4.x.y using yourls.passwordExistingSecret instead of yourls.password

Context

Helm releases managed by Weave Flux.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Summary

For the ingress backend, I would like to be able to specify serviceName and servicePort.

Motivation

As an SRE, I don't want someone to try to ClickOps an upgrade in the UI. We should have the ability to block certain admin paths.

Describe the solution

I will put in a PR this afternoon.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

1.8.1

Description

If I choose a different than 80 port for mi service, the ingress not recognize the service, because in the "ingress template" the servicePort is hardcoded to 80

values.yaml

service:
  type: ClusterIP
  port: 8080

templates/ingress.yaml

  - host: {{ .name }}
    http:
      paths:
        - path: {{ default "/" .path }}
          backend:
            serviceName: "{{ template "yourls.fullname" $ }}"
            servicePort: 80

Expectation

When you change the port in the service, the ingress should see that service

values.yaml

service:
  type: ClusterIP
  port: 8080

Posible solution:

Adding the value from values.yaml is exists.

templates/ingress.yaml

  - host: {{ .name }}
    http:
      paths:
        - path: {{ default "/" .path }}
          backend:
            serviceName: "{{ template "yourls.fullname" $ }}"
            servicePort: {{if .Values.service.port}}{{.Values.service.port}}{{else}}80{{end}}

Reproduction steps

No response

Context

No response

• I've read the Troubleshooting First Steps
• This request isn't a duplicate of an existing issue, opened or closed
• I've read the docs and followed them (if applicable)
• This is not a personal support request that should be posted on the YOURLS Discourse community

Describe the bug
CORS Error - Missing Allow Origin

To Reproduce
Steps to reproduce the behavior. This is mandatory if you expect someone to fix the problem. Example:

1. Install helm chart
2. Expose service through ingress (Traefik 2.x <-> AWS Loadbalancer), add CNAME in DNS
3. Set up app, try to create link
4. In network tab CORS Missing Allow Origin error will appear, nothing will happen

Expected behavior
Being able to create a link.

Actual behavior
CORS Error

Screenshots
If applicable, add screenshots to help explain your problem.

Versions
Tag 1.7.9 official docker image

Additional context
AWS, Classic LB, Traefik as ingress, DNS entry as CNAME.

CORS plugin does not change anything, adding extra headers in .htaccess does not change app's behaviour too. yourls-allow-aliases results in empty error during activation:

Plugin generated unexpected output. Error was: 

Debug mode enabled does not show anything related to this in logs.

Additionally, not everything seems to be hosted via HTTPs, but that's other issue.

Any ideas how to approach this problem from app's side?

• I've read the guidelines for Contributing to YOURLS Projects
• This request isn't a duplicate of an existing issue
• I've read the docs and followed them (if applicable)
• This is not a personal support request that should be posted on the YOURLS Discourse community

Describe the bug

Release "yourls" does not exist. Installing it now.
Error: validation failed: unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta1"

To Reproduce
Steps to reproduce the behavior:

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T21:03:42Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

1. helm upgrade --install yourls --namespace yourls yourls/yourls

Expected behavior
Chart installed correctly

Actual behavior

apiVersion is not correct.

Mariadb stable chart is not deprecated in favor of Btnami Mariadb which fix the apiVersion error too : https://github.com/bitnami/charts/blob/master/bitnami/mariadb/templates/_helpers.tpl#L4

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Summary

i want to manage installing plugins from the same helm chart.

Motivation

• keeping helm chart as single source for the infra-as-code of the Yourls instances.
• keeping helm chart as single source for config-as-code
• Complying with the release engineering principles about immutable infra
• Managing plugins lifecycle from helm chart
  and this is the trigger of motivation ; installing this plugin: https://github.com/peterberbec/yourls-keyword_charset_length

Describe the solution

We can design our default values in a case if a user wants to install this chart, he will give something like this :

plugins:
  - name: key_char_len
     url: https://raw.githubusercontent.com/peterberbec/yourls-keyword_charset_length/master/plugin.php
  - name: plugin_xyz
     url: https://something/xyz/plugin.php

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps and frequent issues guides.

Version

1.9.2

Description

I've set up YOURLS with the helm chart and just added the relevant values like Domain. When the Deployment finished and I access the Website

Forbidden

You don't have permission to access this resource.

The Logs say:

AH01276: Cannot serve directory /var/www/html/: No matching Director Index (index.php,index.html) found, and server-generated directory index forbidden by Options directive

Expectation

Install the helm chart and access the Website without issues.

Reproduction steps

1. Install the helm chart
2. Access the URL defined in the values

Context

values.yaml:

image:
  debug: true

yourls:
  domain: doma.in
  username: user
  password: "password"

service:
  type: ClusterIP

ingress:
  enabled: true
  ingressClassName: "nginx"
  hostname: doma.in
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  tls: true

mariadb:
  auth:
    rootPassword: "loooooongpassword"
    database: yourls_db
    username: yourls_user
    password: "password"

@LeoColomb is something missing? Not sure what you had in mind

• I've read the Troubleshooting First Steps
• This request isn't a duplicate of an existing issue, opened or closed
• I've read the docs and followed them (if applicable)
• This is not a personal support request that should be posted on the YOURLS Discourse community

Describe the bug
The minor release bump from 1.3.2 to 1.4.1 contains breaking changes:

• mariadb was replaced by MySQL
• breaking changes in values file were made

To Reproduce

1. Try to upgrade from 1.3.2 to 1.4.1 without changing existing values.

Expected behavior
Major version bump on breaking changes (to 2.0.0 in this case)

Actual behavior
Minor version change is breaking

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

1.8.2 (chart 4.0.4)

Description

When yourls.schema is set to https, the pod's readiness probe changes from

failureThreshold: 6
httpGet:
  path: /admin/install.php
  port: http
  scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

to

failureThreshold: 6
httpGet:
  path: /admin/install.php
  port: https
  scheme: HTTPS
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

However, the pod never passes this check:

Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  3m23s                 default-scheduler  Successfully assigned gosubme/yourls-84cccbf8cd-ztppj to adevkube02
  Normal   Pulling    3m22s                 kubelet            Pulling image "docker.io/yourls:1.8.2"
  Normal   Pulled     3m8s                  kubelet            Successfully pulled image "docker.io/yourls:1.8.2" in 13.936229479s
  Normal   Created    3m7s                  kubelet            Created container yourls
  Normal   Started    3m7s                  kubelet            Started container yourls
  Warning  Unhealthy  19s (x14 over 2m29s)  kubelet            Readiness probe failed: Get "https://10.1.174.160:443/admin/install.php": dial tcp 10.1.174.160:443: connect: connection refused
  Warning  Unhealthy  13s (x6 over 63s)     kubelet            Liveness probe failed: Get "https://10.1.174.160:443/admin/install.php": dial tcp 10.1.174.160:443: connect: connection refused
  Normal   Killing    13s                   kubelet            Container yourls failed liveness probe, will be restarted

Expectation

Pod readiness check expected to Just Work.

Reproduction steps

Deploy helm release with yourls.schema set to https.

Context

The URLs generated by YoURLs use HTTPS regardless of the value of schema, likely due to TLS on the ingress resource.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps and frequent issues guides.

Version

5.0.6

Description

https://github.com/YOURLS/charts/blob/main/charts/yourls/Chart.yaml#L21

this line should not be there, or it needs to be modified:

comparison failed: chart requires kubeVersion: ^1.20.0 which is incompatible with Kubernetes v1.21.9-eks-0d102a7

Expectation

No response

Reproduction steps

No response

Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps and frequent issues guides.

Version

1.9

Description

thanks for the fix in #158

I installed the new chart version and I saw that mariadb is now being used, however in my value I use externalDatabase (mysql on aurora), so I just disabled mariadb: with enabled: false

upgrade went smoothly, I see the ghcr.io/yourls/yourls:1.9 image running in kubernetes, however when visiting the /admin/ page YOURLS says

• on top: [YOURLS version 1.9](http://yourls.org/download) is available. Please update!
• on bottom: Powered by YOURLS v 1.8.2

so I'm a bit confused, following the docs there should not be much else to do but I see this version mismatch and I'm not sure if it's the chart, the database or the docker image.

any hint? thanks

Expectation

No response

Reproduction steps

No response

Context

No response

The page https://hub.helm.sh/charts/yourls/yourls mentions 1.7.3
What's needed to make it reflect version updates as they are released?

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

1.8.2

Description

While attempting to do a Helm chart upgrade from v4.2.2 to v4.2.3 encountered errors while trying to provide existing credentials. Looking into the yourls secret created within the k8s cluster I noted that it only contains password and username while the use of the existingSecret value to point to it is expecting to find yourls-password

Expectation

When attempting to do a Helm upgrade without specifying the yourls.password or yourls.existingSecret you get presented with the following:

    'yourls.password' must not be empty, please add '--set yourls.password=$YOURLS_PASSWORD' to the command. To get the current value:

        export YOURLS_PASSWORD=$(kubectl get secret --namespace "yourls" yourls -o jsonpath="{.data.yourls-password}" | base64 --decode)

However, if you look at charts/yourls/templates/secrets.yaml, it does not create the yourls-password key, so there is a disconnect in expected values. Either the yourls-password key needs to be created or the subsequent validation and usage checks updated to look for password instead`.

Reproduction steps

1. Run helm install yourls yourls/yourls --version 4.2.2 --namespace yourls-test --create-namespace
2. Run helm upgrade yourls yourls/yourls --version 4.2.3 --namespace yourls-test --set mysql.auth.existingSecret=yourls-mysql --set yourls.existingSecret=yourls
3. Witness the failure
4. Run kubectl get secret --namespace yourls-test yourls -o jsonpath="{.data.yourls-password}" see it shows no value
5. Run kubectl get secret --namespace yourls-test yourls -o jsonpath="{.data.password}" confirm it does have a value

Context

No response

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: .github/renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: packageRules[0]: packageRules cannot combine both matchUpdateTypes and versioning. Rule: {"matchDatasources":["helm"],"matchUpdateTypes":["minor","patch"],"versioning":"npm","bumpVersion":"patch"}, packageRules[1]: packageRules cannot combine both matchUpdateTypes and versioning. Rule: {"matchDatasources":["helm"],"matchUpdateTypes":["major"],"versioning":"npm","bumpVersion":"minor"}

Describe the bug

mariadb fails to start without persistence

logs on yourls-mariadb-0 pod say
mkdir: cannot create directory '/bitnami/mariadb/data': Permission denied

To Reproduce
Steps to reproduce the behavior:

1. create values.yaml

persistence:
  enabled: false

2. helm install

helm install --name yourls yourls/yourls -f values.yaml

Expected behavior

components should start without error

Actual behavior

permission failures. see above

Versions
helm chart version yourls-1.1.2

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

1.8.2

Description

A Helm release install with ingress enabled and TLS true creates a Service which passes traffic to yourls-pod-name:443, while the pod itself is only listening on :80. This results in the ingress controller noting that the traffic is invalid.

Expectation

Traffic be passed to a port on which the pod(s) is listening.

Reproduction steps

Deploy a Helm release with

ingress:
  enabled: true
  <snip>
  hosts:
    - name: example-site.tld
      path: /
      tls: true
      tlsSecret: example-site-tld-tls

Context

A current workaround is to deploy - in parallel - a separate Service and Ingress object with the same selector, but only passing traffic to pod:80.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Submission validity

• This is not a personal support request, that should be posted on discussions community.
• I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Self troubleshooting

• I've read the documentation and made sure to follow it.
• I've read the troubleshooting first steps guide.

Version

2.1.1

Description

the default values and values.schema.json are misleading and outdated comparing with the real usage in templates/*.

in default values, you have:

ingress:
   rules:

But in templates/ingress.yaml, you have

{{ range .Values.ingress.hosts }}

Expectation

consistency between values.yaml, values.schema.json as well as the injection of values in templates

Reproduction steps

explained above

Context

explained above