Automating Code Commit to Build, Deploy, and Notify with GitLab Webhook in the Beetle System

Background

The original code compilation process required developers to manually go to the DevOps platform after submitting code, click to compile, wait for success, then click to deploy, and wait again before testing, which caused frequent context switching and reduced efficiency. To address this, an automatic flow was designed to publish dependency packages, compile, and deploy immediately after code submission.

Current Process and Problems

Existing Beetle compilation and deployment flow

After developers submit code, they must go to the Beetle branch detail page; if a JAR package needs to be released, they must click “publish JAR” before compiling, wait for the JAR to be published, then click compile, wait for success, and finally click deploy. Forgetting to publish the JAR leads to compilation failure, requiring a re‑compile after publishing. All these manual steps waste developers’ time.

Problems

Commit and compilation are independent; how to link them?

The system is unaware of code submissions; how to detect them?

For projects that require a JAR, how to ensure the JAR is published before compilation?

How to eliminate the waiting time in Beetle?

Approach

GitLab Webhook Feature

Webhooks can trigger a user‑defined URL when specific events occur, such as a new code push or issue creation. By configuring a webhook to listen for push or merge‑request events, GitLab sends a POST request with event data to the Beetle system, which can then process the information.

Solution Design

Use GitLab webhook to listen for push actions and send commit information to Beetle.

When creating a new branch, add options to enable “auto‑compile after push” and “auto‑deploy”, with a required deployment IP if selected.

Add the same options on the branch detail page.

Use a diff check to determine whether a JAR package must be published before compilation.

During the process, send WeChat messages to users when the workflow starts or fails.

Flow Diagram

Diff Check for JAR Publication Before Compilation

Since project dependencies are stored in a contract directory, the system checks whether the submitted code modifies any files under contract . If such changes exist, a JAR package must be published before compilation.

Beetle receives commit information and calls the diff API to decide if a JAR needs to be published.

If no JAR is required, compilation proceeds directly.

If a JAR is required, it is published first; upon success, automatic compilation starts. If publishing fails, a message is sent to the commit author.

After compilation finishes, automatic deployment and related CI configurations are triggered.

CI tasks such as static code analysis, test execution, and coverage reporting are run, and results are notified to the commit author.

User Notification

Success or failure events that require user attention are sent via enterprise WeChat, enabling developers to respond promptly.

User Adoption and Benefits

724 projects have enabled automatic compile/deploy.

Over 7,000 branches have used the feature.

Average daily usage reaches about 350 automatic compile/deploy runs.

Reduces the time developers wait before proceeding to the next stage.

Prevents failures caused by forgetting to publish a JAR.

Conclusion

From the usage statistics, the automatic compile/deploy feature significantly reduces the frequent manual steps and waiting time for developers and testers. When auto‑compile and auto‑deploy are configured, the entire workflow—including JAR publishing, compilation, deployment, static code scanning, test execution, and coverage—happens automatically after code submission, thereby also decreasing the amount of user inquiries.

To learn more about ZhiZhuan’s engineering practices, follow the public account below!