2024-11-06 Golang Continued

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."