Menu
Safe Push process for pushing changes to the IntelliJ repository. Use when pushing code changes to remote.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | safe-push |
| description | Safe Push process for pushing changes to the IntelliJ repository. Use when pushing code changes to remote. |
This guide covers the Safe Push process for pushing changes to the IntelliJ repository.
Safe Push is a system that ensures code changes pass all required tests before being merged to protected branches (like master). It's powered by Patronus.
The safePush.cmd script in the repository root provides command-line access to Safe Push without needing the IDE.
# Push current HEAD to master (most common)
./safePush.cmd HEAD:master
# Push specific commit to master
./safePush.cmd <commit-hash>:master
# Push from feature branch to master
./safePush.cmd HEAD:master # while on feature branch
# Dry run (test without pushing)
./safePush.cmd -dry-run HEAD:master
-autosquash Automatically squash fixup! commits (default true)
-dry-run Run tests without push
-emergency Skip tests and push directly (USE ONLY IN EMERGENCIES)
-verbose Verbose output
-help Print help
After starting a Safe Push you'll receive a Patronus URL like:
https://patronus.labs.jb.gg/robot/<uuid>
Always print this URL back to the user — it is their primary handle for the run (link to share, cancel button, restore-branch button). The <uuid> segment is the robot id.
You can also track the Safe Push directly: check current status, enumerate failing checks, drill into a specific attempt, or babysit a long-running robot until it finishes. All of that is in the [[patronus]] skill — pick it up when the user asks for status or when offering to follow up. It's reasonable to proactively suggest tracking or babysitting once the Safe Push is in flight; the user can say no. The [[patronus]] skill also documents the hand-off to [[teamcity-cli]] when an individual TC build needs deeper inspection.
Cancel and restore-branch actions stay in the browser.
Use ./safePush.cmd -emergency ONLY for:
DO NOT use Emergency Push for:
When writing tests that spawn external processes (like bazel.cmd), ensure required environment variables are passed:
// In BUILD.bazel for java_test targets:
env_inherit = [
"LOCALAPPDATA", // Windows
"PROCESSOR_ARCHITECTURE", // Windows
"USERPROFILE", // Windows
"HOME", // Unix/macOS - required for bazel cache directory
],
The Bazel sandbox does NOT inherit environment variables by default. Use env_inherit to explicitly pass variables from the host environment to tests.
#ij-builds Slack channel for infrastructure issues#ij-qa-watch#patronus-support, #ij-builds, #ij-qa-watchPluginize a Product DSL module set by hand-writing a wrapper plugin module next to its feature modules. Use when promoting modules out of an aggregate module set (e.g. `essential`, `ide.common`) into a bundled plugin so products can include or omit them through normal plugin wiring, when updating bundled plugin registration for such a wrapper, or when fixing tests whose plugin loading logs show a missing wrapper plugin for a former module set.
Pluginize a Product DSL module set by hand-writing a wrapper plugin module next to its feature modules. Use when promoting modules out of an aggregate module set (e.g. `essential`, `ide.common`) into a bundled plugin so products can include or omit them through normal plugin wiring, when updating bundled plugin registration for such a wrapper, or when fixing tests whose plugin loading logs show a missing wrapper plugin for a former module set.
Extract an optional dependency from a plugin module into a new content module. Use when making a library dependency optional by separating integration code into its own module.
Extract an optional dependency from a plugin module into a new content module. Use when making a library dependency optional by separating integration code into its own module.
How to manage module dependencies in IntelliJ codebase. Use when adding or modifying module dependencies in iml files.
Guidelines for structuring and developing IntelliJ remote development modules. Use when working on Remote Development features.