Review nebari dependencies and identify which need updates
Context
We need to update our stuff.
Value and/or benefit
Our stuff will be updated
Anything else?
No response
This is related to us double checking our internal helm charts and docker services, in order to update outdated tools for example traefik
At least in the context of Terraform/OpenTofu versions and required providers versions, this task will be made simpler by #2862 by consolidating the location of their configurations into constants.py
I've been looking into this and there’s quite a bit of variety across our codebases. Just within our two main repositories, we manage several different types of dependencies:
nebari
- Binaries (e.g., OpenTofu and Kustomize)
- Helm charts (e.g. JupyterHub, Grafana, Keycloak, Rook and Argo Wofklows)
- Terraform providers
- GHA actions
- Docker images (e.g conda-store, Nebari images and Traefik)
- Python packages
- k8s apps (e.g., EKS add-ons and nvid-device-plugin)
nebari-docker-images
- Python packages
- System packages
- GHA actions
- Base images
Beyond these, we also have dependencies in other repositories such as:
To get a sense of what can be updated, I ran Renovate on forks of both nebari and nebari-docker-images. Here are the summary issues it generated:
- https://github.com/marcelovilla/nebari/issues/3
- https://github.com/marcelovilla/nebari-docker-images/issues/2
While these reports aren’t fully comprehensive—some dependency types will require custom Renovate rules—they still provide a useful high-level overview of what’s out of date.
@dcmcand, @viniciusdc, and I synced yesterday and agreed that before updating all these dependencies or setting up something like Renovate, our first step should be to identify which dependencies actually need updating due to security vulnerabilities. To do this, I suggest we start by leveraging GitHub Dependabot Alerts, and potentially complement it with tools like Google’s OSV Scanner. That said, I’m not entirely sure how well these tools cover things like Helm charts or Terraform providers—we might need to look into that further.