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.
Related
When I run " helm upgrade ." , new modified changes in dependencies list are not updating.
Process we followed : Post doing required changes to the existing values file in helm chart, packaging it using "helm package ." and pushing packaged tar to s3 using s3 plugin.
In the another parent helm chart, we are mentioning above packaged tar file details like name,version and s3 repository link under dependencies list in requirements.yaml file.
successfully executing the helm dependency update also .
later, when executing helm upgrade it is showing like
client.go:229: [debug] checking 38 resources for changes
client.go:512: [debug] Looks like there are no changes
Helm unable to identify the new changes made to the dependencies list.
Please help to fix issue
When using yarn-berry, should I apply the unplugged to the git repository when implementing zero-installs?
As far as I know, in the case of zero-installs, we proceed with yarn start immediately after receiving
git clone from the git repository.
However, because of the Unplugged Folder, we have to proceed with yarn installs inevitably.
Of course, there are ways to put UnpluggedFolder in git repository using git-ignore, but I'm not sure if this is the correct way to run zero-installs.
When I tried yarnstart
$ yarn start
C:\Users\com\Desktop\zero3\project\.pnp.cjs:25991
Error.captureStackTrace(firstError);
^
Error: Required unplugged package missing from disk. This may happen when switching branches without running unplugged packages must be fully materialized on disk to work).
Missing package: open#npm:8.4.0
Expected package location: C:\Users\com\Desktop\zero3\project\.yarn\unplugged\open-npm-8.4.0-df63cfe5dules\open\
gitignore
# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
# dependencies
/node_modules
# testing
/coverage
# production
/build
# misc
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.yarn/*
!.yarn/cache
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions
# !.yarn/unplugged
I am trying to add a rabbitmq service using a bitnami helm chart. the chart contains one dependent helm chart which is called common.
The whole application itself is deployed using a parent helm chart and each service has its own separate helm chart.
the Helm chart structure looks like this-
\myapp
\charts
\service1
\service2
\service3
\messaging
\charts
\common
\templates
\chart.yml
\values.yml
When i ran "helm dependency update" from the 'messaging' dir, it downloaded a common-1.x.x.tgz file. i extracted the contents and placed it in the \messaging\charts\common folder
the original messaging\templates\chart.yml (rabbitmq helm chart) contained the following entry
dependencies:
- name: common
repository: https://charts.bitnami.com/bitnami
tags:
- bitnami-common
version: 1.x.x
because i cannot download during the "Helm install" execution i had to download the dependent helm charts beforehand and save them as a local dependency. After downloading the common.tgz file, i extracted the contents and updated the dependencies in the messaging\templates\chart.yml as follows
dependencies:
- name: common
repository: 'file://charts/messaging/charts/common'
tags:
- bitnami-common
version: 1.x.x
If i do "helm install messaging ." from \myapp\charts\messaging directory, the service gets deployed without any error. But when the application's parent helm chart is deployed i always get this error
"Error: found in Chart.yaml, but missing in charts/ directory: messaging"
Can someone please point out the mistake in the configuration? I moved around the contents of the common folder around multiple location, had them as tgz file, updated the repository path relative to the messaging directory instead of parent helm chart location, but in all cases, the installation of the messaging service fails with the above error
You don't need to unpack the charts/*.tgz file. If they're in that directory (and still packed up) then Helm will use them to run the deployment. Helm won't contact the external chart repository on its own, only when you run the helm dependency commands.
After you run helm dep up your filesystem layout should look like
myapp
\-- charts
\-- messaging
+-- charts
| \-- rabbitmq-8.15.3.tgz
|-- templates
| +-- deployment.yaml
| \-- service.yaml
+-- Chart.yaml
\-- values.yaml
You're ready to go in this state. Don't unpack anything.
If you need to copy this setup across a network boundary, include the charts/*.tgz files when you do it. It doesn't matter that Chart.yaml or requirements.yaml references an Internet location; helm install will only use those local archives.
I had a similar issue and it was because a developer had placed the Charts and templates etc in the charts directory. I kept getting errors saying it couldn't find directories so moved all the charts into a helm-charts directory instead as the charts directory is managed by Helm. When I updated the repository listing to pull from the new directory, my issue was resolved. I got the idea from this issue's comments and it worked. https://github.com/helm/helm/issues/2887
The use case is as follows:
overall-concern/
charts/
cloudformation-chart/
kubernetes-chart/
shared-library/
Both the Cloudformation and Kubernetes charts rely on the shared library. If I specify
it as a dependency in those charts, however, I need to do helm dependency update and
it will be copied into those charts' charts/ subdirectory and a Chart.lock file will
be generated. That seems unnecessary.
On the other hand, if I symlink the chart:
overall-concern/
cloudformation-chart/
charts/
shared-library -> ../../shared-library
It works, but I receive a warning when running helm template that there are symlinks
in the path, leading me to think that this is not intended or is otherwise deprecated:
walk.go:74: found symbolic link in path: ... (paths elided) ...
Is there a blessed solution that will let me use a local chart without treating it as
a formal "dependency" in Helm 3?
I am trying to make git ignore the opencv2.framework I have imported into my project. However, even though I am adding opencv2.framework into my .gitignore, every time I run git status on my terminal, all the opencv2.framework files are showing up as new files. Could anybody help? Thanks! This is what my .gitignore file looks like: (I wrote opencv2.framework under ##Various Settings)
# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore
## Build generated
build/
DerivedData/
## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/
opencv2.framework/
## Other
*.moved-aside
*.xccheckout
*.xcscmblueprint
## Obj-C/Swift specific
*.hmap
*.ipa
*.dSYM.zip
*.dSYM
## Playgrounds
timeline.xctimeline
playground.xcworkspace
# Swift Package Manager
#
# Add this line if you want to avoid checking in source code from Swift Package Manager dependencies.
# Packages/
# Package.pins
.build/
# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/
# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts
Carthage/Build
# fastlane
#
# It is recommended to not store the screenshots in the git repo. Instead, use fastlane to re-generate the
# screenshots whenever they are needed.
# For more information about the recommended setup visit:
# https://docs.fastlane.tools/best-practices/source-control/#source-control
fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots
fastlane/test_output
Just in case, see if git status changes after:
cd /path/to/my/repo
git rm -r --cached opencv2.framework/
If it does (and you don't see anymore opencv2.framework/ files), commit your current state.
You need to execute the git rm -r --cached:
in the parent repo of the folder to remove (parent of opencv2.framework/).
Do add and commit (and eventually push), in order to record that deletion from the git repo (but not from the disk, thanks to the --cached option);
in order to delete those tracked files, as a .gitignore rule only applies to untracked files.