feat(librariangen): scaffold Java language container for Librarian #3926
Conversation
The Docker build and test steps were moved from the GitHub Actions workflow to a local script. This is because the base Docker image is not accessible from GitHub Actions. The CI workflow now only runs the Go tests. The new `build-docker-and-test.sh` script can be used to build the Docker image and run the version check locally.
|
|
There was a problem hiding this comment.
The "internal" folder having only librariangen folder is strange. It's because we are not going to move other internal things (such as "hermetic_build") to the folder.
Shall we remove the "internal" folder?
For example, Python team's Dockerfile is at https://github.com/googleapis/google-cloud-python/tree/main/.generator.
| "testing" | ||
| ) | ||
|
|
||
| func TestRun(t *testing.T) { |
There was a problem hiding this comment.
The argument parsing logic is to be in the shared module, so that each language container doesn't need to implement the argument parsing logic and its tests. https://github.com/googleapis/librarian/pull/2489/files#diff-704975122c152b21ff033c97bc92e9f3dc765402bf278620a3f88df835a9dd43R41
There was a problem hiding this comment.
So you don't have to write many test cases for argument parsing.
There was a problem hiding this comment.
That's great, but let's integrate that in when it's ready.
|
It's nice that this started with small. |
This is a Go convention for non-exported packages that is enforced by the compiler and I think it's appropriate for our use-case: https://go.dev/doc/go1.4#internalpackages. |
|
@meltsufin Thank you for the info. The "internal" folder or its parent doesn't have go.mod. I'm not sure the "internal" is recognized as a package. Would you be willing to experiment the "internal" folder is indeed following https://go.dev/doc/go1.4#internalpackages ? I think it's a matter of whether a symbol (In another go program's |
This change introduces the initial scaffolding for
librariangen, a containerized Go application that will serve as the Java-specific code generator within the Librarian pipeline.The primary goal of this change is to establish the foundational components for the Java language container, including:
librariangenCLI application: Written in Go, this will be the entry point for Java code generation tasks invoked by Librarian. It currently includes basic command dispatching and support for--version.Dockerfile: This creates a minimal container image for librariangen.This scaffolding is the first step in implementing the full code generation logic within the Librarian system, eventually replacing the Java hermetic code generation system.
The code is largely adapted from the Go language container at https://github.com/googleapis/google-cloud-go/tree/main/internal/librariangen.
Fixes: googleapis/librarian#2500