Sometimes, we want to limit the library generation for certain part of a repository while we want to keep the rest generated and released. For example, the language container may not be ready to process certain libraries in google-cloud-python yet.

With #2039 feat: add per-library override configurations to .librarian/config.yaml merged recently, we can add the configuration per library there.

This issue is not about having release freeze in the team.

Cases

Let's call this is "blocked" state of a library.

• For "librarian generate" and "release init" without --api or --library, Librarian CLI should exclude the libraries with blocked status.
  • librarian tag-and-release does not take --library option.
• If the library is explicitly specified via --api or --library, Librarian CLI should generate (or release-init) the library regardless of the blocked state. This allows manual invocation of check while the main branch of the SDK repository still has the library in the blocked status.
• For a hybrid library, it should be possible to mark the library as "blocked" for "release init" only, while the "generate" flow works for it. The maintainer may want to release the library manually by invoking .

Idea

We now have id and next_version for per-library configuration (#2039). Let's add generate_blocked and release_blocked fields (boolean; false by default) in the per-library configuration to control the behavior.

As the new fields are better maintained by humans rather than CLI/automation, we put it in the config.yaml file, rather than the state file.

The logic is going to be implemented in around https://github.com/googleapis/librarian/blob/main/internal/librarian/generate.go#L91 and https://github.com/googleapis/librarian/blob/main/internal/librarian/release_init.go#L136.

Document

Ensure we have the same level of documentation for the two new fields as we have next_version.