Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Feature: Renovate for Dependency Management

Abierto
  • ¿Algo no está bien?
#750 2 comentarios 3 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
github-actions, helm
Área
ci-cd, devops

Línea de trabajo

Comienza con la configuración propuesta de Renovate y la integración de Renovate en GitHub Marketplace; después, revisa cómo el repositorio gestiona los charts de Helm, los workflows y los lockfiles. Se considera terminado cuando una configuración de Renovate acordada está integrada, las actualizaciones de dependencias se generan según lo previsto y cualquier comportamiento de automerge está cubierto por las comprobaciones de CI del repositorio.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Description of the change

Similar to what I have seen, and done in other repositories, I believe it would be beneficial to get renovate on this repository.

It will generate PRs like this one for example: https://gitlab.com/GeorgeRaven/raven-helm-charts/-/merge_requests/201, so that we can automate a significant portion of the maintenance work related to updating patches etc.

I extend renovate with custom managers so we can manage the version of anything in any file using regex.

This is my generic configuration that handles 90% of my use cases in my repositories:

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:recommended"
    ],
    "packageRules": [
        {
            "description": "Automerge patches",
            "excludePackageNames": [],
            "matchUpdateTypes": [
                "patch"
            ],
            "matchCurrentVersion": "!/^0/",
            "automerge": true
        }
    ],
    "customManagers": [
        {
            "customType": "regex",
            "managerFilePatterns": [
                "/^.*$/"
            ],
            "matchStrings": [
                "\"?v?(?<currentValue>(?<major>0|[1-9]\\d*)\\.(?<minor>0|[1-9]\\d*)\\.(?<patch>0|[1-9]\\d*)(?:-(?<prerelease>(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+(?<buildmetadata>[0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?)\"?\\s+# renovate: datasource=(?<datasource>.*) depName=(?<depName>.*)"
            ],
            "extractVersionTemplate": "^v?(?<version>.*)$"
        }
    ]
}

The only thing to note is the addition of an automerge rule, this will create and automate merging of semver patches. Thus eliminating the maintenance of and keeping on top of them.

Benefits

  • higher automation, reducing maintenance work
  • ensures all dependencies can be managed even those in non-standard locations that might be forgotten about
  • works with just about everything, helm, github workflows, lockfiles, etc
  • highly configurable depending on what everyone would like to see, including automated bumping of helm package versions, when a sub-dependency is updated.

Possible drawbacks

  • higher automation in particular patch automerging requires good Ci setup to ensure a high-bar of trust in merges. (This will be a seperate issue I will likely open shortly to do with kubeconform etc)
  • while I can self-host it, I would probably recommend that it is added to the github repo directly via the marketplace: https://github.com/marketplace/renovate/ for long-term support.
  • some level of trust is required in renovate to give it access to create branches, from which it creates PRs to the default branch (unless otherwise specified)

Additional information

There are many ways to skin the proverbial renovate cat. Please let me know what you think.

Lenguaje dominante
Go Template
Estrellas
536
Forks
316
Merge medio
4 d 16 h
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextcloud/helm

Todos los issues de nextcloud/helm

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.