Getting stuck with Go Modules? JFrog helps the community move forward.

UPDATE: As of May 1, 2021 – GoCenter central repository has been sunset and all features will be deprecated. For more information on the sunsetting of the centers read the deprecation blog post

One of the exciting things about being a Golang developer today is the strong community that supports the evolution of the language that was developed at Google. The founders of Golang were open to getting engineers involved early-on and the community-centric approach has now become an asset to Go itself. Today, engineers around the world continue to contribute open-source packages, modules, and frameworks and consistently help comment on new ideas and collectively resolve issues as Go moves towards its 2.0 roadmap. The JFrog Community Engineering team has played a part in that evolution and today, we’re highlighting the individual engineers who have been making contributions to the community from the start of GoCenter in January 2019. Let’s hear a few of their stories:

Ankush – Dev Manager, Community Engineering @ JFrog explains why you should use a GoProxy

“The motivation behind GoCenter is to improve the Golang ecosystem by helping developers adopt Go modules successfully and serve rich metadata that allows developers to make decisions. The community day shifts allow us to carry forward this vision. During the shift, we observe failure notifications that provide early signals about modules not being created or served successfully. There might be multiple reasons for this; one is missing requirements such as incorrect module names, etc. We use Stack Overflow, social media, various Slack channels and VCS systems to understand the context of the issues. We can then help users by engaging with them and helping them submit pull requests to fix the problem.

“For example, a few months ago I was on a Kubernetes Slack channel and found out that one of the packages, Apache Thrift was not available to the community. I Googled Apache Thrift and found that a lot of projects were failing because they weren’t using a GoProxy. When I checked on GoCenter, I noticed we had it available there. Once I figured out this issue, I helped spread awareness and explain that this is exactly why developers should use a GoProxy that guarantees availability and immutability. On GoCenter, we store every version of each module so it’s always available. After this, I spent more time figuring out the solution and how else I could help the community. In doing so, I also realized that they changed the name of the module, so helping the community understand that moving to a new version of the module would fix the name issue as well.”

Elio – Senior Software Engineer explains Pseudo-versions issues

“Our main goal on Community Support Days is to make sure that modules on GoCenter are working properly and serving the community the best we can. We don’t want people to miss Go module content that should be available; for instance, if they can’t fetch it, we actively work with them on finding out why. We monitor the system to make sure it’s healthy, we observe all the events and we make sure that based on our safety and health checks, we can have an opinion to resolve unhealthy modules. When we identify that things are missing or that there may be a latency issue, we fix those. When we see things aren’t available because the authors of a module may have caused an issue on their side, we communicate that to them and work with them to get it fixed so people can consume those modules as dependencies.

“In one example on Slack, a user reported an issue with how we were handling the pseudo-versions on GoCenter. We worked with the user to describe the optimal and desired user experience and were able to resolve the issue the same day. That was when we introduced the pseudo-version fix feature. We made it easy for them so they didn’t have to go to their mod files and make the fixes there. We just published a JFrog blog about this and I wrote a piece about this pseudo-versions issue on Dev.to here.”

Mitali – Software Engineer talks about Security Mitigation

“Recently, we’ve added free security scanning of Go Modules to GoCenter and I’ve been mitigating security issues for the community since. From our database of vulnerabilities, I’ve been making pull requests on GitHub to let the community know that a certain project has an issue that came up in the CVE public database. I’ve made it my mission to track whether or not the security issues get resolved or if there are still issues present in that module version. I also look at the dependencies list to see if there are versions of that module that were made secure after the one they chose to use in a specific project. In many cases, I can advise the module author on which version is the newest and the safest to use.”

Mahesh – Software Engineer explains how Artifactory uses GoCenter as a GoProxy

“Most issues that I help with are related to Artifactory and how to set up the remote repo. Last year, a developer team was creating some local Go repositories in Artifactory and used that as their endpoint which didn’t work for them because the documentation in Artifactory explains that you first need to create a virtual repo and then add the local under the virtual one. After this, you use the virtual as the actual endpoint. Once this was explained and understood, I was able to walk this developer team through setting that up; we helped them understand how GoCenter works as a GoProxy and where the environment variable can be seen in Artifactory.”

Shivaram – Senior Software engineer talks about helping teams migrate to Go Modules

“One thing I’m proud of is being able to help our community migrate Go projects to using Go modules with the Go 1.13 release. Converting existing projects to use Go modules can be very challenging, especially if the project has evolved through Golang’s many earlier attempts at package management solutions. ETCD.io was one such project which also posed other complex challenges as it used code generators like protobuf and golang static analysis tools that were not module aware and various categories of tests in builds including unit, functional, integration and end-to-end tests which all had to be modified to work with modules. I ensured all the tests passed and the commit had 544 files. It was one of the largest single commits made in GitHub and a personal favorite moment for me.”

Working with the Community on Go Modules

As highlighted in the stories above, the JFrog Community Engineering team has helped solve a number of issues as dependency management in Go evolves and have been able to directly help developers better understand how to develop their Go modules, deal with dependency issues, understand pseudo-versions, and mitigate security risks.

“I love the community support day shifts – they give us exposure as a user in GoCenter and what issues might come up. The shifts even help us understand best practices to use to prevent these errors, which helps us understand how the Go community is actually experiencing Go module failures and how we can be better at addressing those.” – Stanley

To learn more about how we’re supporting Golang’s evolution, we invite you to get involved! You can comment on our GitHub issues here or speak directly to one of our engineers by joining our GoCenter Slack channel.

Who We Are

	Ankush – Dev Manager, Community Engineering My goal is to identify and solve issues faced by bigger developer communities and make sure that the solutions my team produces are high in quality. I love the pace of startups. My favorite breakthrough was when I was able to prove that Helm doesn’t scale beyond 100k charts due to the design of the index file – I gave a talk and from that day on, I launched fully into the community.
	Arvind – Senior Software Engineer I worked for the federal government before JFrog. What really drove me to JFrog is the community aspect – solving pain points for fellow developers. At JFrog, I lead building the UI layer for all the central repositories and other community products we build.
	Mitali – Community Software Engineer Before JFrog, I was at Cisco working with Artifactory. I really liked the Artifactory product and noticed that JFrog had an opening for a software engineer developing new features for GoCenter. I also noticed that the role was a little different from usual software developer roles and I was enticed by the idea of working on the community team.
	Elio – Senior Software Developer I’ve spent the last 10 years working in Brazil as an engineer for big corporations, telco’s, small startups and banks. At JFrog, I design the architecture and build our central repositories to support the unpredictability of the load.
	Stanley – Technical Solution Developer I’ve been in software development management for most of my career. I have a very strong passion for QA and DevOps which affords me the desire to help build and support developer tools to enable faster releases. At JFrog, I resolve bugs, develop test automation, provide the state of the issues in a release and am responsible for the quality of the release.
	Shivaram – Senior Solution Developer I joined JFrog as a senior solution developer initially contributing to the partnerships team, but soon became a core contributor to the development of centers. I love being exposed to new products! At JFrog, we always work on new products and learn all the things we don’t know on-the-spot. I like that I get to work on Golang and ElasticSearch, and microservers on Kubernetes.
	Mahesh – Sr. Solutions Engineer When I joined JFrog as a Sr. Solutions Engineer, I was initially working with the templates we support like Azure, Artifactory, AWS and OpenShift. I’m currently working with automating the pipeline work – how the code gets deployed into the clusters. My future goal is to integrate all of our solutions with the JFrog Pipelines product and support new features, especially from GoCenter.
	Rimas – Senior Solutions Engineer Before JFrog I was working in the Kubernetes space where I co-founded Helm. I’ve been in senior engineering roles for the last 15 years, mostly, managing teams or doing DevOps, automation of CI/CD, supervising projects, and building out products in the K8’s and Helm space. Today, I work with monitoring, alerting, logging and leveraging cloud-native to make our jobs easier. I love working on the community engineering team supporting open-source projects.