Using helm I know you can disable a dependency in requirements.yaml using a condition.
However, I have a dependency copied into the charts/ directory and expanded because I need more control over it.
Is there is any way to conditionally include this dependency given that it's not included via requirements.yaml but rather through expanding in the charts/ folder?
Yes, according to helm dependency docs:
Starting from 2.2.0, repository can be defined as the path to the directory of the dependency charts stored locally. The path should start with a prefix of "file://". For example,
# requirements.yaml
dependencies:
- name: nginx
version: "1.2.3"
repository: "file://../dependency_chart/nginx"
If the dependency chart is retrieved locally, it is not required to have the repository added to helm by "helm repo add". Version matching is also supported for this case.
Related
We have enabled depedebot alert on our repository. But depedebot is not opening new PR for some of vulnebrites.
For example :
Below is one of alert I see
`
The latest possible version that can be installed is 2.4.2 because of the following conflicting dependencies:
zip-folder#1.0.0 requires lodash#~2.4.1 via archiver#0.11.0
zip-folder#1.0.0 requires lodash#~2.4.1 via a transitive dependency on zip-stream#0.4.1
The earliest fixed version is 4.17.21.
`
But Zip-folder is not updated on npm repo so far as fix on lodash was relased 9 year ago i.e;v 1.1.1 but loadash latest version 4.17.21 and it's using v 1.1.0
As zip depedency is transitive should I update v1.1.1 in my package.json manually. Will it override the vesion used by zip or there is some alternative of this approach?
I want to give a shot to a coursier artifact fetcher, but we are using Artifactory for maven and ivy repositories, I am not sure how to set it up in with coursier. In documentation they provide this example of ENV. variable:
export COURSIER_REPOSITORIES="ivy2Local|central|sonatype:releases|jitpack|https://corporate.com/repo"
If I have artifactory ivy repo with this URL: http://myivyrepo.tld/joint-ivy-releases which also have some custom pattern :
[org]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev])(-[classifier]).[ext]
How can I set this up with Coursier ?
I have an SBT project that depends on two snapshot dependencies. Every time I build it, it goes off to the remote repository to fetch the dependencies. This is true even if I set offline := true.
When I look at how it is trying to resolve the local dependencies, the build is saying it is looking in "local", i.e., ~/.ivy2/local/... -- which is a nonexistent directory.
The jars are in ~/.ivy2/cache/... and this is where SBT downloads them when it pulls the dependencies from the remote server.
I have searched my .sbt and .scala build files and the string "local" does not appear in them in connection with a repository or cache.
SBT is at version 0.13.11 building against scala 2.11.8.
Why is SBT doing this, and how can I get it to see the cached jars?
If you want to prevent SBT from trying to download from official repositories you could simply create a file project/offline-repositories:
[repositories]
mirror-central: file:////nexus/central
mirror-maven-central-org: file:////nexus/maven-central-org
...
(/nexus/central and /nexus/maven-central-org should contain a (partial) mirror of what you need offline)
Then call sbt with the sbt.repository.config property configured:
-Dsbt.override.build.repos=true \
-Dsbt.repository.config=./project/offline-repositories
For Reference:
http://www.scala-sbt.org/0.13/docs/Proxy-Repositories.html
How to prevent SBT from trying to download from official repositories?
EDIT
If you want to use your ~/.m2 cache:
[repositories]
mirror-central: file:////home/XXXXX/.m2/repository
mirror-maven-central-org: file:////home/XXXXX/.m2/repository
...
This apparently is because in my Ivy cache I had a file named ~/.ivy2/cache/com.xxx/xxx-utils/ivy-2.3.2-SNAPSHOT.xml.original , which the build was trying and failing to parse. I'm not sure where this file came from; conceivably it was put there manually ages ago.
I'm currently develop a set of libraries that progressively add more features.
For example, in my solution, I have a Foo project which defines some basic feature set, an additional project, Foo.Web, for web specific implementations and Foo.Web.Tokens for even more specific features. Foo.Web.Tokens depends on Foo.Web which depends on Foo.
I'm attempting to build separate nuget projects so a user only needs to reference those dependencies they need. I'm versioning the assemblies with GitVersionTask, so after build, they all get the same version number and I'm using the replacement tokens for nuget when building from a project so that the nuget packages all have the same version number.
My problem is that when I try reference a prerelease version of either Foo.Web or Foo.Web.Tokens nuget is unable to resolve the dependency on Foo. If, for example, I have published a 1.1.0.0-alhpa0001 package for each of the assemblies, when I try and update Foo.Web, nuget shows this error:
Install-Package : Unable to resolve dependency 'Foo (≥ 1.1.0.0)'.
Using the -Pre argument doesn't change this. A Foo.1.1.0-alpha0001.nupkg does exist but I feel like nuget won't resolve it because it's not a stable version, and I'm letting nuget automatically detect the dependencies from the solution using the following command:
.\.nuget\NuGet.exe pack source/Foo.Web/Foo.Web.csproj -Build -Version 1.1.0.0-alpha0001 -symbols -IncludeReferencedProjects
How do I properly allow the Foo.Web prerelease package reference the Foo prerelease package of the same version?
The IncludeReferencedProjects option seems to pull the version from the assemblyinfo.cs of the referenced project.
setting the AssemblyInformationalVersion attribute to the desired nuget package version seems to work as you want it to.
eg
[assembly: AssemblyInformationalVersion("1.1.0-alpha0001")]
I have a package and nuspec file that I build by copying the dll for the assembly in question into a lib folder which is in the same folder as my nuspec file. This all works fine and dandy, no issues here.
I have a second package which references the first via nuget so to build it's package I followed the same process but added in a dependency element into the nuspec file. When I do my copy from release to lib it also takes the dependent dll.
Since this is marked as a dependency can I remove this from by lib folder (I want it to be downloaded via nuget, not included in the current package).
I'm not sure I got your scenario exactly, but in general I could say: Depending on how you create your NuGet packages, you might not even have to specify the dependencies. Given a Visual Studio solution with the following structure:
* Solution1
- Project1
* projectfile1.csproj
- using external libraries through NuGet
- project reference to Project2
* nuspecfile1.nuspec
- Project2
* projectfile2.csproj
* nuspecfile2.nuspec
If you run nuget pack projectfile1.csproj, any NuGet packages included in Project1 will automatically be included as dependencies in your NuGet package, even if you haven't specified the dependency in your nuspec file. These dependencies will then also include the versions of the external libraries at the time of creation of the package.
As of NuGet 2.5, there is also a new feature to automatically resolve dependencies between projects in the same solution. With v2.5 you can run the following command:
nuget pack projectfile1.csproj -IncludeReferencedProjects
This will also result in a NuGet dependency to Project2. And in case Project2 isn't exposed as a NuGet package (i.e. it has no nuspec file), the Project2's dll will be included as a file in Project1's NuGet package.
After doing some testing it turns out that adding a dependency does not require the dll to be in the lib. The dependency assumes it will be resolved by Nuget. This can be confirmed by creating a new package file via the nuget GUI and adding a few dependencies. Note how they do not show up in the lib folder after save.