I want to know how to use place holders in requirements.yaml file for versions field or if there is a way to Implementation Automatic dependencies version
dependencies:
- name: nuclei-wallet-async
version: {{ .Values.version_dep }}
repository: http://127.0.0.1:8879/charts
Declared the version_dep in values.yaml file but doesn't work
In general there is no support to parameterize requirements.yaml. Also refer to the official helm documentation for requirement files. It makes no sense as you cant guarentee the helm package functionality if somebody puts random version numbers into the chart dependencies.
An option would be to use conditions.
For example you could introduce values to be evaluated by a condition in requirements.yaml.
# requirements.yaml
dependencies:
- name: subchart1
repository: http://localhost:10191
version: 0.1.0
condition: subchartversion1.enabled
- name: subchart1
repository: http://localhost:10191
version: 0.2.0
condition: subchartversion2.enabled
But that would be only a workaround and no best practice.
Related
I am trying to create a helm based operator and for most part, I've got it working. However I need to make sure that the subcharts are installed before the operator is trying to create resources from those subcharts. For e.g I have mongodb community-operator helm chart as a subchart. However, when I deploy the operator i get the below error
failed to install release: unable to build kubernetes objects from release manifest: resource mapping not found for name: "test-mongodb" namespace: "default" from "": no matches for kind "MongoDBCommunity" in version "mongodbcommunity.mongodb.com/v1"
ensure CRDs are installed first.
Looks like its trying to create the mongodb instance before actually installing the operator and crds. How can I force it to first install the subcharts and then try to create mongodb instance.
inside the chart.yaml you can use the condition & tag
dependencies:
- name: subchart
version: 0.0.1
repository: https://chart.github.io/helm-charts
condition: subchart.enabled
so if the chart name as subchart is not installed already in cluster it will throw the error.
Official doc : https://helm.sh/docs/chart_best_practices/dependencies/
if you have multiple sub charts as dependencies you can also go with the tags
I have a Helm Umbrella Chart that I'm trying to write which has dependencies on 2 charts (for simplicity's sake). Chart A and Chart B. Both Chart A and Chart B have defined dependencies on Chart C. When I'm writing the Umbrella chart I specify a dependency on Chart A and B. When I try to install my Umbrella chart I get an error:
Error: INSTALLATION FAILED: serviceaccounts "chart-c" already exists
My guess is this is happening because both Chart A and Chart B are trying to install the Chart C app. How do I manage these dependencies in my Umbrella Chart?
I think you can do that with alias.
Example: In the dependencies section of the Chart.yaml file.
dependencies:
- name: mongodb
version: 12.1.2
repository: https://charts.bitnami.com/bitnami
alias: mongodb
condition: mongodb.enabled
- name: mongodb
version: 12.1.2
repository: https://charts.bitnami.com/bitnami
alias: mongodb-tracing
condition: mongodb-tracing.enabled
You can read more about alias here
I need something similar in Dart to what Maven has with a parent-pom dependencyManagement structure.
I have 2 modules in Dart, api and core.
api/pubspec.yaml:
...
dependencies:
http: '>=0.12.0 <0.13.0'
meta: '>=1.0.0 <2.0.0'
...
core/pubspec.yaml:
...
dependencies:
api:
path: ../api
# Meta is added again with a version number
meta: '>=1.0.0 <2.0.0'
redux: '4.0.0'
...
So if I change the dependencies in core/pubspec.yaml to 'any' if they already exist in api/pubspec.yaml:
...
dependencies:
api:
path: ../api
# No version number is needed, the exact version will come from the dependency
meta: 'any'
redux: '4.0.0'
...
This seems to be working, but the official site does not mention this feature, instead:
The string any allows any version. This is equivalent to an empty version constraint, but is more explicit. Although any is allowed, we don’t recommend it.
Is this an unintended good use case of the 'any' or this is a bad idea? (I am confident api dependency will always exist and declare meta, they are all my modules.)
I have added mysql in requirements.yaml. Helm dependency downloads the mysql chart
helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "nginx" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading mysql from repo <our private repository>
Deleting outdated charts
But when I do helm install my_app_chart ../my_app_chart
It gives error
Error: found in Chart.yaml, but missing in charts/ directory: mysql
You don't have to add it to the control version system, you just download them again if for some reason you have lost them (for example when you clone the repository). To do this, execute the command:
helm dependency update
The above command will download the dependencies you've defined in the requirements.yaml file or dependencies entry in Chart.yaml to the charts folder. This way, requirements are updated and you'll have the correct dependencies without worrying about if you updated them also in the control version system.
I updated .helmignore
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/
charts/
It contained charts/ I removed the entry and it worked
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/
I have encountred the same error message when I first started learning how to use libcharts, I used chart.yaml to specify the dependency of the libchart like so:
chart.yaml
...
dependencies:
- name: mylibchart
version: 0.1.0
repository: file://path/to/libchart
and in that libchart chart.yaml data was like this:
apiVersion: v2
name: lib <-- this was causing the error to occur (should be mylibchart instead)
description: A Helm chart for Kubernetes
type: library
version: 0.1.0
appVersion: "1.16.0"
so as you can see the name specified in the dependencies has to be the same name of the chart/libchart.
I'm using helm charts to deploy around 15 microservices. There is a parent helm chart with requirements.yaml where the all the required microservices are listed as dependencies.
Sample requirements.yaml file:
dependencies:
- name: service1
repository: "#stable"
version: <version>
- name: service2
repository: "#stable"
version: <version>
- name: service3
repository: "#stable"
version: <version>
- name: service4
repository: "#stable"
version: <version>
condition: false
When I run helm dependency update all the charts that are listed as dependency are downloaded. There are scenarios where few services are under development and are not required to be deployed in production.
We have different artifactory for prod and non-prod environment and the disabled services are not in prod artifactory. Hence it gives an error saying helm chart missing. I understand that the condition flag doesn't install the dependency but how can I stop it from downloading the dependency ?
It might come a bit late, but I sorted out a similar problem recently and I thought it might help others to share. You can use the condition key when declaring dependencies in your Chart.yaml:
dependencies:
- condition: gitea.cache.builtIn.enabled
name: memcached
repository: https://charts.bitnami.com/bitnami
version: 4.2.20
With the bit in values.yaml being as follows:
[...]
gitea:
cache:
builtIn:
enabled: true
[...]
This example is extracted from the fantastic gitea helm chart repo and should be self explanatory. However, you can take a look at Helm documentation
Be aware that if there are nested charts more than 2 levels deep, helm2 might misbehave so I recommend you to take a look at Helm3 for that.
Finally please note that in my case (as I'm following a small detour when deploying Helm charts, the check for the condition happens when rendering the helm chart not when running helm dependency update