The problem
"Oops, fixing broken build" commits are a universal developer experience. Most
IDEs will happily let you push compilation-broken code — CI catches it minutes
later, and you've already broken main for everyone else.
I wanted a fast, local feedback loop that blocks the push before it leaves your machine, without waiting on CI and without slowing down healthy pushes.
What I built
- IDE push guard — hooks into IntelliJ's native push dialog via
the
prePushHandlerextension point. - Smart compile scope — compiles only the modules containing
changed files; automatically falls back to a full project build when build
files (
build.gradle,pom.xml, …) or file deletions are in play. - IDE problem check — if IntelliJ already reports errors in the files being pushed, the push is blocked instantly, skipping a redundant compile.
- Terminal push guard — installs a managed
pre-pushhook so pushes from the terminal, Sublime Merge, SourceTree, or GitHub Desktop are also protected. - Compilation Checker tool window — a right-side panel that lists errors from the last check with file icons; double-click to jump to the offending line.
- Refresh action — fix errors, click refresh in the block dialog, and the push flow resumes without restarting.
Design decisions
- Two surfaces, one source of truth. Both the IDE push and the
terminal hook write to the same
.idea/pre-push-checker/last-run.log, which the IDE parses into the tool window so the experience is identical wherever the push came from. - Idempotent hook installation. The
pre-pushhook is written respectingcore.hooksPath, worktrees, and submodules, and chains non-destructively with any existing user hook. - Escape hatch. The
PRE_PUSH_CHECKER_COMMANDenvironment variable lets teams substitute any custom check command (e.g. a lint+test combo) without forking the plugin. - Fail fast, then fail well. If the IDE already knows there are errors, don't waste seconds on a compile — surface them immediately.