41 lines
4.8 KiB
Markdown
41 lines
4.8 KiB
Markdown
---
|
|
name: workflow-constraints
|
|
description: Strict behavioral constraints for Jenkins, staging deployments, git investigations, and background tasks.
|
|
trigger: always_on
|
|
---
|
|
|
|
# 1. Strict Background Task Control
|
|
- **Rule:** Do not run continuous background polling, background loops, or test suites unless explicitly requested.
|
|
- **Rule:** If the user says 'stop' or 'don't run anything', kill all tasks immediately and stop launching new ones.
|
|
|
|
# 2. No Unauthorized Jenkins Deployments
|
|
- **Rule:** Never trigger Jenkins CI/CD pipelines (`jn run`) automatically. Always wait for explicit user approval before deploying via Jenkins.
|
|
|
|
# 3. Hot Deploy & Visual Verification
|
|
- **Rule:** In `ai-pr-review`, never `git push` without first hot-deploying to staging using `just deploy-code aipoc` and running the relevant sandbox E2E test to allow visual confirmation, and wait for human visual verification to complete before git push.
|
|
- **WARNING (Jenkins Conflict):** Hot-deploying creates manual containers on `aipoc`. If you subsequently trigger a Jenkins deployment to `aipoc` (`ai-pr-review-ansible-deploy`), the Ansible playbook will fail with a Docker naming conflict (`Error when allocating new name: Conflict`). You MUST SSH into `aipoc` and manually remove the conflicting containers (`sudo docker rm -f <container_id>`) before running the Jenkins deployment.
|
|
|
|
# 4. Git Investigation Constraints
|
|
- **Rule:** Confine code investigations and debugging to actual code diffs. Never rely lazily on git commit messages to determine what changed.
|
|
|
|
# 5. Git Push and Gatekeeper Constraints
|
|
- **Rule:** Before running `git push`, you MUST ensure the git working tree is completely clean (`git status`). Untracked scratch scripts or uncommitted formatting changes will cause the pre-push gatekeeper to hang indefinitely.
|
|
- **Rule:** If a `git push` task hangs, kill it, investigate and clean the working tree (using `git clean -fd` or `git restore`), and retry. NEVER poll a hanging push task in a loop.
|
|
- **Rule:** NEVER use `git push --no-verify` to bypass a hanging pre-push hook. The hook is hanging due to environment state, not failing tests.
|
|
# 6. Strict Process Termination (Zombie Cleanups)
|
|
- **Rule (CRITICAL):** NEVER kill processes using broad wildcard name matches (e.g., Get-Process | Where-Object Name -match "cargo|rustc"). This causes collateral damage to globally deployed binaries (e.g., in ~/.local/bin/).
|
|
- **Rule:** When cleaning up zombie files or locked compiler processes, you MUST strictly target the process by its Path to ensure it originates from the current workspace's arget/ directory (e.g., Get-Process | Where-Object { $_.Path -match "\\target\\" } | Stop-Process -Force).
|
|
|
|
# 7. GCP / GCR Troubleshooting Constraints
|
|
- **Rule (GCR 403 Forbidden):** Google Container Registry obscures `404 Not Found` errors as `403 Forbidden` for security reasons. If a `docker pull` or `podman pull` from GCR fails with `403 Forbidden`, you MUST explicitly verify that the image path and tag are 100% correct (checking prefixes, project IDs, and typos) before assuming it is an IAM or Service Account permission issue.
|
|
|
|
# 8. GCP Infrastructure Provisioning (gcloud & Cloud Armor)
|
|
- **Rule (Cloud Armor IP Limits):** GCP Cloud Armor security policies strictly enforce a limit of **10 IP ranges per rule** (`--src-ip-ranges`). When allowlisting large services (like Atlassian Bitbucket which has 11+ IP CIDR blocks), you MUST split the ranges across multiple rules (e.g., priority 1000 and 1001) to prevent the `Only a maximum of 10 IP ranges allowed per rule` API error.
|
|
- **Rule (gcloud Idempotency):** When writing bash scripts to provision GCP infrastructure, NEVER use bare `gcloud ... create` commands. You MUST wrap all creation commands in existence checks (e.g., `if ! gcloud ... describe ... >/dev/null 2>&1; then ... fi`) to ensure the script is fully idempotent and can be safely retried upon failure.
|
|
|
|
# 9. Rust Build System & Toolchain Resilience
|
|
- **Rule (SChannel VPN Revocation Bypass):** To prevent `CRYPT_E_NO_REVOCATION_CHECK` errors when fetching crates over corporate VPNs, ensure `.cargo/config.toml` specifies `[http] check-revoke = false`.
|
|
- **Rule (sccache Caching Efficiency):** When using `sccache` as `rustc-wrapper`, set `incremental = false` under `[profile.dev]` in `.cargo/config.toml`. `sccache` cannot cache incremental compilation units.
|
|
- **Rule (sccache Daemon Recovery):** If `sccache` fails with socket error 10054 (`connection forcibly closed`), restart the daemon using `sccache --stop-server; Start-Sleep -Seconds 1; sccache --start-server` before retrying compilation.
|
|
- **Rule (cargo-llvm-cov Toolchain Matching):** Always set `LLVM_COV` and `LLVM_PROFDATA` environment variables to the matching `rustup` toolchain LLVM binaries (`.../lib/rustlib/<target>/bin/llvm-cov.exe`) to prevent LLVM profile format version mismatches.
|