Go

Today, Kubernetes is the defacto standard if you want to run container workloads in a production environment. As we set out to build our next generation of products, and run them smoothly in the cloud, we needed to move to Kubernetes too! In the process of building tools like KubeXray and GoCenter we learned a whole bunch. At the Amsterdam Kubernetes/Cloud-Native Meetup I presented a talk in which we walked through our lessons learned and how we’re running it at scale.

In this webinar, we’ll look at Go modules and why it is such an improvement over vendoring, we’ll show you why dependency management is so important, and we’ll build a CI/CD pipeline for your Go projects using GoCenter!

This is the fourth and final post in the blog series on using GitHub Actions with the JFrog CLI and JFrog Artifactory. In this post we’ll look at building an app and uploading it, together with the BuildInfo, to Artifactory. If you have any thoughts on what the next series of posts should be, let me know here or on Twitter!

I was lucky enough to get access to GitHub Actions over the Christmas break and wanted to use that new found technology to build a few tutorials. Since I also just started at JFrog, I combined learning the JFrog Technology with building awesome actions. Last week’s article built a Go app using Artifactory, the CLI and GitHub Actions and this one will continue that by publishing the Go app as a module.

With the release of Go 1.11 also came the introduction of Go Modules. That introduction was awesome, but it did leave a few issues unsolved. Using GOPROXY is an “all or nothing” exercise, meaning you have to get all your modules from the same place, or your build will fail.

I was lucky enough to get access to GitHub Actions over the Christmas break and wanted to use that new found technology to build a few tutorials. Since I also just started at JFrog, I combined learning the JFrog Technology with building awesome actions. The first article was building a custom GitHub Action and this one will continue that work by building an awesome Go app.

Go 1.11 introduced support for Go Modules and with it the ability to do proper dependency management. As the Go community moves towards the adoption of modules more and more, the question is “Why not stick with vendoring?”

In today’s world everyone is building apps, most times those apps are event-driven and react to what happens around them. How do you take those apps to, let’s say, a Kubernetes cluster, or let them communicate between cloud and on-premises, and how can developers and non-developers work together using the same tools? Let’s break down the title a bit…

Developers want to build better software faster, I don’t think any developer would disagree on that and with the release of Go 1.11 a long-awaited (and debated) feature became available, Go modules! With that amazing addition to the Go language, you can now really have repeatable builds because all the information is put in a single go.mod file and during the build the Go compiler will get all the right versions for you.

Not too long ago Flogo introduced a new Go API that allows you to build event-driven apps by simply embedding the Flogo engine in your existing Go code. Now you can use the event-driven engine of Flogo to build Go apps while using the activities and triggers that already exist and combining that with “regular” Go code.