local-action-verification
Set up a repository for local GitHub Actions verification using act, so Jules can validate CI before pushing
Works with
--- name: local-action-verification description: Set up a repository for local GitHub Actions verification using act, so Jules can validate CI before pushing license: Apache-2.0 --- # Local Action Verification with act You are setting up a repository so that Jules (or any agent) can run GitHub Actions workflows locally using [act](https://github.com/nektos/act) to verify code changes pass CI before pushing. ## What You're Setting Up Two scripts and an agents.md section that enable local CI verification: 1. **install-act.sh** — Installs `act` if missing (platform-aware, sudo fallback) 2. **run-act.sh** — Runs `act` in the background with log polling to avoid agent timeouts 3. **AGENTS.md section** — Instructions Jules reads to know how to use these scripts ## Setup Steps ### Step 1: Copy scripts to the repository Copy the `scripts/` directory from this skill into the target repository at `scripts/act/`: ``` Target structure: scripts/act/ ├── install-act.sh └── run-act.sh ``` Make sure the scripts are executable: ```bash chmod +x scripts/act/install-act.sh scripts/act/run-act.sh ``` ### Step 2: Add instructions to AGENTS.md Append the following section to the repository's `AGENTS.md` file (create it if it doesn't exist). This is how Jules discovers the local verification capability: ```markdown ## Local CI Verification Before pushing code or opening a PR, verify changes pass CI locally using `act`. ### Prerequisites - Docker must be running - If `act` is not installed, run: `bash scripts/act/install-act.sh` ### How to Verify 1. Read `.github/workflows/` to find the CI workflow and identify the job ID 2. Run the verification script: ```bash bash scripts/act/run-act.sh "push -j <JOB_ID>" ``` With matrix: `bash scripts/act/run-act.sh "push -j <JOB_ID> --matrix <KEY>:<VALUE>"` 3. If the run fails, read the log output, fix the code, and re-run 4. After verification, clean up: ```bash rm -f act_output.log git checkout <any unintended file changes> ``` ### Configuration - Timeout: `ACT_TIMEOUT=900 bash scripts/act/run-act.sh "..."` (default: 600s) - Poll interval: `ACT_POLL=15 bash scripts/act/run-act.sh "..."` (default: 10s) - Custom image: pass `-P ubuntu-latest=node:20-bookworm` in the arguments for faster pulls ``` ### Step 3: Update .gitignore Append these entries to `.gitignore` if they don't already exist: ``` # act artifacts act_output.log .secrets ``` ### Step 4: Print next steps for the user Tell the user: 1. Docker must be installed and running on any machine (or Jules VM) where verification runs 2. `act` will be auto-installed on first use via `scripts/act/install-act.sh` 3. If workflows require secrets, create a `.secrets` file (KEY=VALUE format) — never commit it 4. Commit all generated files ## Troubleshooting - **Docker not running**: `act` requires Docker. Ensure the Docker daemon is started. - **Image pull slow**: First run downloads ~2GB+. Use `-P ubuntu-latest=node:20-bookworm` for faster pulls. - **ARM64 issues**: On Apple Silicon, add `--container-architecture linux/amd64` to act arguments. - **Secrets required**: Create a `.secrets` file and pass `--secret-file .secrets` in the act arguments. - **Timeout**: Increase with `ACT_TIMEOUT=1200 bash scripts/act/run-act.sh "..."`. ## Resource References - [Troubleshooting Guide](resources/troubleshooting.md) — Detailed solutions for common issues
More Deployment & CI/CD skills
azure-enterprise-infra-planner
microsoft/azure-skills
Architect and provision enterprise Azure infrastructure from workload descriptions. For cloud architects and platform engineers planning networking, identity, security, compliance, and multi-resource topologies with WAF alignment. Generates Bicep or Terraform directly (no azd). WHEN: 'plan Azure infrastructure', 'architect Azure landing zone', 'design hub-spoke network', 'plan multi-region DR topology', 'set up VNets firewalls and private endpoints', 'subscription-scope Bicep deployment', 'Azure Backup for VM workloads'. PREFER azure-prepare FOR app-centric workflows.
azure-kubernetes-app-deploy
microsoft/azure-skills
Use when deploying an existing web application or API to an already-running Azure Kubernetes Service cluster. Detects the framework, generates a Dockerfile and Kubernetes manifests, validates against AKS Deployment Safeguards, and deploys with verification. WHEN: deploy app to AKS, deploy to existing AKS cluster, containerize app for Kubernetes, generate K8s manifests for Azure, set up CI/CD for AKS, my AKS deployment is failing safeguard checks, I have a Django/Express/Spring Boot app to run on AKS. DO NOT USE FOR: creating or provisioning an AKS cluster (use azure-kubernetes), assessing migration to AKS Automatic (use azure-kubernetes-automatic-readiness), or deploying to non-AKS targets like Web Apps, Container Apps, or Functions.
finetuning
microsoft/azure-skills
Fine-tune models on Microsoft Foundry using SFT (supervised), DPO (preference), or RFT (reinforcement with graders). Covers dataset preparation, training job submission, deployment, and evaluation. USE FOR: fine-tune, SFT, DPO, RFT, training data, grader, distillation, fine-tuned model, training job, large file upload, calibrate grader, deploy fine-tuned model, evaluate fine-tuned model. DO NOT USE FOR: general model deployment without fine-tuning (use deploy-model), agent creation (use agents), prompt optimization without training (use prompt-optimizer).

