I am trying to add my modified version of vega as a local package as a dependency via:
yarn add vega#file:../vega/packages/vega
however, when I then do yarn, it tells me my package is invalid:
invalid: vega#5.22.1 /Users/alex/Documents/Work/Research/vega_profiler/VegaProf.nosync/editor/node_modules/vega
I think this is because it tries to match the version with the one in my package.json, which does not contain version information for the local package. However, I don't know how to address this.
While trying to add/update a dependency to a helm chart I'm getting this error. No helm plugins are installed with the name helm-manager.
$ helm dep update
Getting updates for unmanaged Helm repositories...
...Unable to get an update from the "https://kubernetes-charts.storage.googleapis.com/" chart repository:
failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden
...Unable to get an update from the "https://kubernetes-charts.storage.googleapis.com/" chart repository:
failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. Happy Helming!
Error: no cached repository for helm-manager-1067d9c6027b8c3f27b49e40521d64be96ea412858d8e45064fa44afd3966ddc found. (try 'helm repo update'): open /Users/<redacted>/Library/Caches/helm/repository/helm-manager-1067d9c6027b8c3f27b49e40521d64be96ea412858d8e45064fa44
afd3966ddc-index.yaml: no such file or directory
The stable and incubator repositories of the Helm charts have been moved to a new location.
You must updated URI in charts.yaml (or requirements.yaml) to point to the new repositories in order to let the Helm dependency resolver find the correct location.
Name
Old Location
New Location
stable
https://kubernetes-charts.storage.googleapis.com
https://charts.helm.sh/stable
incubator
https://kubernetes-charts-incubator.storage.googleapis.com
https://charts.helm.sh/incubator
After that you should be able to run helm dep update without further modifications.
I get this sometimes when there's a mismatch between my Chart.yaml and the configuration of my subchart dependencies.
For instance:
Chart.yaml:
dependencies:
- name: foo
...
- name: bar
...
values.yaml:
foo:
flag: true
# but no entry for bar
It may be an artifact of some other element of my configuration (Artifactory hosting a proxy of the world for Helm) but I find myself running into this frequently enough that I hope this answer may help someone else.
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 signed up for the Github private npm registry beta and followed their instruction: https://github.com/features/package-registry
Works great with npm but I'd prefer using yarn. And while npm has no issues finding the registered package, yarn can't find it at all.
yarn add #omniphx/adminite-adminite-ui-components outputs:
yarn add v1.19.0
info No lockfile found.
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍 Resolving packages...
error Couldn't find package "#omniphx/adminite-ui-components" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
After reading up on private repos with yarn, I thought the trick was due to yarn having a slightly different rc format. Unfortunately, that didn't work either and yarn is still unable to find the private registry.
.npmrc
registry=https://registry.npmjs.org
#omniphx:registry=https://npm.pkg.github.com/omniphx
.yarnrc
registry "https://registry.npmjs.org"
"#omniphx:registry" "https://npm.pkg.github.com/omniphx"
Also confirmed that my github token is set too with yarn config list:
yarn config v1.19.0
info yarn config
{
'version-tag-prefix': 'v',
'version-git-tag': true,
'version-commit-hooks': true,
'version-git-sign': false,
'version-git-message': 'v%s',
'init-version': '1.0.0',
'init-license': 'MIT',
'save-prefix': '^',
'bin-links': true,
'ignore-scripts': false,
'ignore-optional': false,
registry: 'https://registry.npmjs.org',
'strict-ssl': true,
'user-agent': 'yarn/1.19.0 npm/? node/v12.11.1 darwin x64',
email: 'mattjmitchener#gmail.com',
lastUpdateCheck: 1570679687836,
username: 'omniphx',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx'
}
info npm config
{
'//npm.pkg.github.com/:_authToken': 'fake12345',
registry: 'https://registry.npmjs.org',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx',
python: '/usr/bin/python'
}
Any idea?
Resolved
Changed "#myorg:registry" "https://npm.pkg.github.com/myorg"
To "#myorg:registry" "https://npm.pkg.github.com"
I've just run into a similar situation. It seemed that yarn was only looking in the main Yarn package registry for my organization's private package. I had copied the examples from GitHub's Packages documentation for constructing your .npmrc file directly to the .yarnrc file in the project that will be consuming the app, not knowing that the formats were different (I've never had to deal with .yarnrc files before).
However, after updating the .yarnrc file with the correct format that you've mentioned above (which I also found in googling around), yarn successfully found the private package and installed it correctly.
As a heads up, my yarn version: 1.17.3
Steps I Took
Start new terminal session
cd to the project
nvm use (if you have a specific node version to use)
Add the correctly-formatted .yarnrc file to the project. See below for what it looks like.
Manually add the package and version range to the package.json for my private package
Run npm login --registry=https://npm.pkg.github.com --scope=#MyOrg
See the note below on scope / org gotcha's
Run yarn
That worked for me.
.yarnrc
"#myorg:registry" "https://npm.pkg.github.com"
Note: See below for a note on the org / scope name gotcha's
Other Notes
I know that it appears that you don't have any issues with this, given your GH username / scope above, but for anyone else that comes here, the documentation on GH is a little sparse with regards to mapping your username / org name to a scope in the package name. Just remember these little gotcha's here:
The name of your package must always be scoped to your org (or username)
E.g., name: #johndturn/my-package
If your organization has capital letters in it, like MyOrg, just replace them in the name of the package in your package.json and your .yarnrc with lowercase
E.g., name: #myorg/my-package
Note: When authenticating with npm login, I still have kept the uppercase letters in the --scope= argument.
The name of your package doesn't have to be the same name of the repo.
E.g., for a repo called MyOrg/random-prefix.js-lib, you can have name: #myorg/js-lib in your package.json file for the project itself. Then, installing it in other projects will look something like #myorg/js-lib: 1.0.0.
The problem I had is slightly different.
After tried what John suggested I still can't add private registry packages with yarn (but perfectly fine with npm)
Then I realise two things:
For GitHub packages, npm is fine with either
registry=https://npm.pkg.github.com/my-org
or
#my-org:registry=https://npm.pkg.github.com
but yarn only allow the latter syntax.
Docs from Github website only show the first syntax which could cause problems for yarn users.
Another thing is that if you npm login to the private registry but use a .yarnrc file in your project, yarn can't really mix your npm credentials with it. Although it seems behave differently on different environment.
But it would seems to be a best practice to stick with either yarn login + .yarnrc, or npm login + .npmrc (you can still use yarn to manage your packages in both cases)
In Yarn v2+ the setup has changed quite a bit. ".yarnrc" is ignored and only ".yarnrc.yml" is used.
To setup a private registry with a scope and token from env, add something along these lines to the ".yarnrc.yml" file (fontawesome example):
npmScopes:
fortawesome:
npmRegistryServer: "https://npm.fontawesome.com"
npmAuthToken: ${FONTAWESOME_TOKEN}
Documentation: https://yarnpkg.com/configuration/yarnrc#npmScopes
I'm not an expert with npm/yarn so I might be misunderstanding what is happening here, but I don't think package proxying from the npm registry works with yarn yet. Could that be related? When package proxying was released for npm I remember reading comments on Twitter from people that tried it with yarn and it didn't work.
Found the Twitter thread here:
https://twitter.com/github/status/1171832034580451328
It doesn't work with Yarn. As soon as I change the registry url -> Couldn't find package.