2024-11-06 Golang Continued

• Is API-first design supported?  API document generation?
  • https://github.com/folio-org/mod-reporting#api-documentation
• What about code generation? 
• Security footprint and support period lengths? Alignment with FOLIO support periods?
• We already have several frameworks - RMB, folio-spring-base, folio-vertx-lib, etc.  Will we have/need another one for Go?

Today:

• API can be specified in RAML and generate docs, compatible  with the FOLIO docs site. Open API generators are available for Go.
• No code generator for the module but have used code generation for other things. Can generate for a framework or independent from a framework.
• Didn't feel framework was needed for this module but might in the future for others
• Go is very stable and expected to stay at V1 and avoid breaking changes
  • https://endoflife.date/go
  • each release supported  for  approx. 1 year
• External library for accessing PG is very mature, beyond V1 but stable
• Pulling in more components does increase security risk- what are the benefits that make this worthwhile?
  • RFC covers these  points
  • Stability, relatively terse, order of magnitude less memory, optimized for writing the kinds of things we need in FOLIO, fun to write!
  • Readability of code, level of abstraction is less, easy to find your way around
  • No  expectation to rewrite existing modules in Go
• Beta test set with Ramsons

PREVIOUS MEETING:

• Centralized Workflows:

  • Introduced centralized GitHub workflows for Go module development in FOLIO.
  • Two main workflows:
    • Go Workflow: Builds Go software, creates Docker images, and publishes module descriptors.
    • Go Lint Workflow: Runs linting and code analysis tools to ensure code quality.

• Versioning and Releases:

  • Releases are tagged (e.g., 1.6.0), with a V1 tag pointing to the latest release.
  • Modules reference the V1 tag to stay updated with the latest workflow changes.
  • Go version is specified in the project's go.mod file.

• Docker Image Management:

  • For non-main branches:
    • Docker images are built but not pushed to Docker Hub.
  • For the main branch:
    • Docker images are pushed to Docker Hub.
    • Module descriptors are posted to the registry.
    • Release tags push images to the folio-org namespace; otherwise, they go to folio-ci.

• SonarCloud Integration:

  • Used for code analysis but acknowledged to have limited support for Go.
  • Additional linting is performed using Go-specific tools like golangci-lint.

• Vulnerability Checks:

  • Workflows include vulnerability checks that report issues via annotations.
  • Developers are encouraged to fix vulnerabilities by updating dependencies or Go versions.

• Project Configuration:

  • Projects can add extra labels and configure additional linters.
  • Use of make as a build system is expected.
  • Flexibility is provided to projects for additional configurations.

• Cross-Platform Builds:

  • Target OS and architecture is specified with GOOS and GOARCH variables

• Vulnerability Management:

  • Craig: Expressed concern about tracking vulnerabilities across multiple Go modules centrally.
  • Jakub: Suggested that central vulnerability management is a broader discussion beyond CI/CD workflows.

• Building from Source:

  • Wayne: Inquired about prerequisites for building modules from source on different architectures.
  • Jakub and David: Confirmed that installing the Go SDK and make is necessary. Standard Go tools used in workflows can be replicated locally or in other CI systems.

• Architecture Considerations:

  • Wayne: Asked about detecting the required Go version and handling different architectures.
  • Jakub: Explained that the Go version is specified in go.mod, and builds fail if the incorrect version is used. Target architecture for cross-compilation is easily specified via GOOS and GOARCH environment variables.

• Code Analysis and Quality Checks:

  • Maccabee: Raised concerns about SonarCloud's maturity for Go and how it affects module evaluations.
  • Discussion: Acknowledged that Go's tooling differs from Java's, and SonarCloud may not provide all necessary insights.
  • Mark: Noted that the static code analysis subgroup should address these issues and update evaluation criteria accordingly.

• Evaluation Criteria Adjustments:

  • Recognized the need to adjust module review criteria to accommodate Go modules.
  • Emphasized the importance of defining common rules for Go, with the ability to handle exceptions.

• Next Steps:

  • Further discussions planned to address:
    • Centralized vulnerability tracking for Go modules (Security Team).
    • Integration of Go-specific code analysis tools.
    • Updating module evaluation criteria to reflect Go's ecosystem.
  • The static code analysis subgroup will take the lead on these tasks.

00:14:16	Taras:	How will it be integrated with the Jenkins pipelines?
There are some useful Jenkins pipelines that allow developers to build and deploy a particular module from a particular branch in the desired Rancher dev env in one click.
00:16:12	Jakub Skoczen:	I don’t think we will be working on Jenkins pipelines for Go as the focus for new CI/CD work is on GitHub actions. GH actions can also be triggered on demand easilly.
00:16:43	Taras:	Also nightly builds for snapshot envs are controlled by Jenkins pipelines and go-based modules must be included in the nightly updates.
00:17:46	Jakub Skoczen:	Correct, but these rely on already published artefacts (e.g Docker images) so the Go-specific tasks are executed earlier as part of the CI/CD for the module repository.
00:28:50	Marc Johnson:	Replying to "How will it be integ…"
                There is probably an open question about responsibility for support of the Rancher tooling
                Particularly given the ongoing AWS cost reduction and shift of who is responsible for development team environments
00:34:57	Wayne Blair:	How can we detect the required version of go?
00:43:38	Taras:	What is the effort needed to build a go-based module for arm64 architecture?
00:53:13	Maccabee Levine:	"Sonarqube hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified."