Today, the Helm Maintainers are proud to announce that we have successfully completed a 3rd party security audit for Helm 3. Helm has been recommended for public deployment.

Helm, the package manager for Kubernetes, just completed its first security audit. This is one of the benefits of being a CNCF project.

As with every security audit I've been involved with, I learned something new. I was also reminded of some things I've forgotten. Reading the results of the security audit were a benefit to me, personally. They helped with my growth.

Continue Reading »

Working with Go modules whose major version is 2 or greater is different than working version 0 or 1 and is different than doing so with the tools that came before it like dep and glide. There are changes that need to be made to both the module and the way it's consumed. Having had to work through this with semver, here are some practical things I've learned along the way.

Continue Reading »

I'm happy to share that a new major release of github.com/Masterminds/semver, a semantic version package for Go, is here. This is version 3.0.0. This release was the result of following up on feedback, requests, and watching how semver was used in many real world situations. The v1 series is still in wide use and will be supported for some time. The work for that major version now happens on the release-1 branch.

Let's take a look at what's new in v3.

Continue Reading »

Go 1.13 was just released and by default is using a Google operated proxy to fetch module dependencies.

With Go modules came the inclusion of the ability to use a proxy when fetching dependencies in the form of modules. jFrog quickly launched GoCenter to provide a high performance cache. Typically, pulling modules from GoCenter was much faster than getting them from someplace like GitHub. GoCenter was optimized for performance for this use case.

Continue Reading »

Have you ever needed to pick a log package for a Go project? Should you use logrus, glog/klog, the package in the standard library, or something else? The packages have different APIs making changes later a fair amount of work.

This is all made more complex when packages that aren't applications could or should leverage logging. These packages are essentially libraries. Sometimes they do a lot. I find need to be especially true when packages could benefit from debug level logging. As someone pulling packages in that depend on different logging packages it can be a bit of an inelegant mess. Next thing you know, applications have multiple dependencies on packages that do the same thing. Like Kubernetes which depends on 5 logging packages.

Logging is just one example of this problem. There are many others. Most recently I was looking at metrics.

We can do better.

Continue Reading »