feat: add CITrigger interface

[lanmaoxinqing]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @lanmaoxinqing, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the CI triggering logic by introducing a CITrigger interface, promoting better modularity and testability. It enhances the existing ACI build integration to accept additional parameters like templateId and callbackURL, making the CI process more configurable. The changes also include minor cleanups in Python build scripts and an update to a pre-commit hook for improved linting feedback.

Highlights

• CI Trigger Interface: Introduced a CITrigger interface (service/ci_trigger.go) to standardize CI pipeline triggering, promoting better modularity and testability.
• ACI Integration Update: The ACI build triggering mechanism (clients/aci_hack_client.go, clients/aci_hook.go) was updated to support templateId and callbackURL parameters, which are now passed to the underlying aci_hack command.
• Dependency Injection for CI: The EnvController (controller/env.go) now uses dependency injection for the CITrigger interface, allowing for flexible CI integration without direct coupling to specific client implementations.
• Command-line Configuration: New command-line flags (--template-id, --callback-url) were added in main.go to configure the CI trigger dynamically at application startup.
• Python Build Script Cleanup: Removed an unused time import and related heartbeat logging logic from the _build_image function in artifacts_builder.py, simplifying the Docker image build process.
• Pre-commit Linting Verbosity: Enabled verbose output (-v) for golangci-lint in the pre-commit configuration for the api-service, providing more detailed feedback during linting.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a CITrigger interface to abstract the continuous integration trigger logic, which is a great improvement for modularity and testability. The implementation is decoupled from the controller and made configurable via command-line flags. The changes are well-structured and the new interface is clearly defined. I've added one suggestion to improve the configuration handling by adding a warning for incomplete configuration, which will enhance usability and prevent silent failures.

I am having trouble creating individual review comments. Click here to see my feedback.

envhub/main.go (91-96)

The CI trigger is configured only when both template-id and callback-url are provided. If a user specifies only one of these optional flags, the trigger is silently disabled. This can lead to configuration errors that are hard to debug. It's better to log a warning message in this case to alert the user.

if templateId != "" && callbackURL != "" {
		ciTrigger = clients.ACITrigger{
			TemplateId:  templateId,
			CallbackURL: callbackURL,
		}
	} else if templateId != "" || callbackURL != "" {
		log.Printf("warning: both --template-id and --callback-url must be provided to enable the CI trigger; trigger is disabled")
	}