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…
I can hear you think “Part 2?! So there actually is a part 1?” 😱 The answer to that is, yes, there most definitely is a part 1 (but you can safely ignore that 😅). In that part I went over deploying Flogo apps that you built with the Flogo Web UI using the Serverless Framework. Now, with the Go API that we added to Flogo, you can mix triggers and activities from Flogo (and the awesome community) with your regular Go code and… deploy using the Serverless Framework