I am trying to generate mocks in Golang using mockery, and the repo requires v0.0.0-dev.
I ran brew install mockery but that only installs v2.15.0, and thus cannot generate mocks with v0.0.0-dev. How do I use/install mockery v0.0.0-dev? There is not much info online about this
v0.0.0-dev is the "_defaultSemVer" used by mockery when debug.ReadBuildInfo has no embedded build information.
In your case, the binary installed does include said build information, hence the 2.15.0, which is the latest release, as expected.
You should change the dependency to use an actual version (or, if you have to, use the #latest).
Not v0.0.0-dev, which depends on how mockery was built.
Related
I am working on a server migration and upgrade, and I don't code in Ruby at all.
Is there an easy way for me to scan / review the gemfile / installed dependencies to check that latest updated / unpatched dependencies?
The code references to a hundred at least dependencies and I am not sure which are no longer the latest stable version.
You can try bundle with the outdated command and using the --strict parameter to make sure it lists only compatible gems:
bundle outdated --strict
But like I said in my comment above, you usually want to know what you are doing if you plan to upgrade any gem. Any changes to the API or functionality of a gem may break part of or the entire codebase. Make sure you have working backups.
We’ve inherited a GitLab instance of 8.15.5 and we’d like to upgrade. I think the initial install was with an Omnibus Package install although I’m not 100% sure. I’m just noticing now that there’s a gitlab-manifest file in /op/gitlab describing all the different bundled libraries that are in this GitLab instance. There may be additional libraries and possible internal tools installed in addition to the out-of-the-box GitLab v8.15.5.
Question is, if I want to upgrade, what would I need to do if I want to upgrade to, say, version 8.17.x ? Do I maybe test, and install v8.15.5 on a test machine to find out what libraries are there (in the gitlab-manifest) which come out of the box in the Omnibus 8.15.5 GitLab package and then check the differences between the two instances - the one in production and the one on my test machine. And then would I just install the missing libraries before upgrading ?
I've got a hello world opendaylight app (created following the tutorials) which compiles using a mvn clean install, and appears when I run the karaf package that is also generated.
However I am unable to get it to run in another ODL install (downloaded the binary with all the other packages from the website), and even using a
bundle:install mvn:org.andrew.test
results in unable to install bundle (tried copying to deploy and system/org/andrew....)
How do you get a bundle which can be used in another install?
Why do you want to bundle:install instead of feature:install ?
What most existing ODL projects do for you, and what the example generated by the archetype should also show you how to do for your custom org.andrew.test one (have you used the archetype? try it..) is that there is a local karaf/ artifact which correctly depends on the features/odl-something feature of your example, and lets you install it, which will install your bundle/s.
In theory and if you really know what you are doing, you can also get it to work for what you call "in another install" in your question, but you have to use repo-app and what not - most people do not use it like that AFAIK (at least in ODL development); so I wouldn't bother, if I were you.
If you want to learn more about this in general outside of OpenDaylight, the general Karaf documentation manual is not bad. Beware that in ODL we've tweaked a few things though; for example, we have (intentionally) disabled the direct installation from ~/.m2/repository (for better isolation).
I am hitting this error while i try to compile GO code
[root#scsor0014444001 Netapp]# go build -o terraform-provider-xxxx
# github.com/hashicorp/terraform/config
../go/src/github.com/hashicorp/terraform/config/testing.go:9: t.Helper undefined (type *testing.T has no field or method Helper)
[root#scsor0014444001 Netapp]# go version
go version go1.8.3 linux/amd64
Can someone help me in understanding whats wrong here ?
Thanks in advance!
As of the 0.10.3 release, Terraform core now requires Go 1.9 due to the use of the new "test helper" feature.
Since providers depend on some packages from the core system as libraries, this dependency is unfortunately then inherited by the providers too. If you're using vendoring to make Terraform core available to the provider (recommended!) then you can potentially wind back the vendored version to the final commit before this change in order to build with 1.8, though over time this strategy will of course cause the vendored package to fall behind the latest changes.
Upgrading Go to 1.9 should address this in a more permanent way.
Our development team has been fairly small and, until now, all working on a single Visual Studio 2012 solution. We are growing and wanting to create better separation with multiple solutions for different project teams.
However, there are occasions where the code in one solution will want to utilize code from another. We have decided using internal (i.e. private) NuGet packages will be a good way to manage these dependencies.
However, the question has come up on how to deal with multiple versions of the same package that are in different SDLC stages (e.g. Development, QA, Staging, Production, etc.)
Example: If we have these three solutions...
CoreStuff
CoolProject1
CoolProject2
If working in CoolProject1, and we need to utilize code from CoreStuff, we can add the NuGet package. Presumably this package will be the latest Production (stable) version of CoreStuff.
However, what if a developer working on CoolProject2 is aware of some changes in CoreStuff that are currently in Development and wants to utilize that version?
Not sure if the best approach is to create separate packages for each (seems to require changing your package references back and forth depending on what stage the solution is in) or somehow utilize multiple versions of the same package (not sure if that's easy to manage with NuGet).
Anyone tackle something like this?
The first thing to remember is that NuGet will not automatically update your package references, so if you have already 'linked' your solution to the latest stable package of CoreStuff (say 1.2.2) then there won't be any problems if a newer (unstable) version is provided (assuming that the package you're using doesn't disappear from the package repository). Obviously if you upgrade your package reference then you will get the unstable package.
So the simplest solution is to make sure that you 'link' your project to the stable package by getting it via the NuGet package manager before the other package is released. While the UI only allows you to get the latest version, the Package Manager Console can get any version of a package so you could use that to explicitly provide the version number, e.g.:
Install-Package CoreStuff -Version 1.2.2 -Project CoolProject1
If that is not a solution then there are several other options to tackle this problem:
Give the development version a different semantic version that indicates it is a unstable version, e.g. 1.2.3-alpha. In this case CoolProject1 could pull in package CoreStuff.1.2.2 (which should be latest stable version in your repository) and CoolProject2 could pull in CoreStuff.1.2.3-alpha (which would be the latest unstable version).
Have multiple repositories, e.g. one for stable (released) packages and one for unstable (development) versions. Then you can select your packages from the desired repositories. If you wanted to you could make it so that only your release process can push packages up to the stable repository and your CI build pushes up to the unstable one (so that you always have the latest packages available)
If the developer of CoolProject2 just wants to develop against the latest version (but will wait to release CoolProject2 until after CoreStuff v.next has been released) then he could potentially create a local package repository (i.e. a directory on his drive) and put the new package of core stuff there. That way other developers won't even see the package.
The most important thing will be to make sure that you don't get CoreStuff.1.2.2 and CoreStuff.v-next in the same repository if CoreStuff.v-next simply has a higher version number, because in that case the NuGet UI won't let you pick v1.2.2 (but the Package Manager Console does!).
If you would want to switch from one package type to another you'd have to do a manual update (which you always have to do when changing to the next package version anyway), but that's not a bad thing given that this forces a developer to at least check that the update of the package doesn't break anything.