Because... ...Why Not!
This document explores the strategic use of random chance in GitHub Actions workflows. By introducing probabilistic execution paths, teams can simulate real-world unpredictability, optimize resource usage, and experiment with delivery strategies. This approach supports goals such as chaos engineering, canary releases, CI load management, A/B testing, observability validation, and developer engagement.
Definition: Introduce randomness to simulate flaky or unstable environments, helping teams identify brittle tests or infrastructure weaknesses.
Code:
name: Stochastic Testing
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Run tests with random chance
if: env.CHANCE < 20
run: |
echo "Random chance passed ($CHANCE < 20)."
./run-flaky-tests.sh
Expected Outcome: Flaky or long-running tests are executed in approximately 20% of runs, allowing teams to monitor their behavior over time without incurring the cost on every build.
Definition: Gradually roll out a deployment or feature to a small percentage of builds to reduce risk and observe behavior in production-like environments.
Code:
name: Canary Deployments
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Canary deployment
if: env.CHANCE < 20
run: |
echo "Random chance passed ($CHANCE < 20)."
./deploy-canary.sh
Expected Outcome: Only 20% of builds trigger the canary deployment path, enabling safe, incremental exposure of new code or infrastructure changes. This helps detect issues early in a controlled subset of environments before full rollout.
Definition: Reduce the frequency of non-critical jobs (e.g., documentation builds, static analysis) during peak CI load by probabilistically skipping them.
Code:
name: Load Shedding
on:
schedule:
- cron: '0 0 * * *' # Daily
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Conditional build
if: env.CHANCE < 20
run: |
echo "Random chance passed ($CHANCE < 20)."
./build-docs.sh
Expected Outcome: Non-critical jobs are executed only 20% of the time, reducing CI resource consumption while still providing periodic validation of auxiliary workflows.
Definition: Randomly select between two workflow strategies (e.g., caching methods, build tools, test runners) to compare performance, reliability, or cost impact over time.
Code:
name: A/B Testing
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: A/B test strategy A
if: env.CHANCE < 50
run: |
echo "Running Strategy A"
./run-strategy-a.sh
- name: A/B test strategy B
if: env.CHANCE >= 50
run: |
echo "Running Strategy B"
./run-strategy-b.sh
Expected Outcome: Each strategy is executed in roughly 50% of runs, enabling side-by-side comparison of outcomes (e.g., duration, success rate, resource usage) without requiring separate branches or manual toggles.
Definition: Occasionally trigger synthetic errors or anomalies in the CI/CD pipeline to validate that monitoring, alerting, and logging systems are functioning as expected.
Code:
name: Noise Injection
on: [push]
jobs:
inject_noise:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Inject noise
if: env.CHANCE < 20
run: |
echo "Injecting synthetic error"
./inject-noise.sh
Expected Outcome: Roughly 20% of runs simulate an error condition, allowing teams to verify that observability tooling (e.g., dashboards, alerts, incident response) is correctly configured and responsive to real-world failure signals.
Definition: Introduce occasional fun or motivational messages into the workflow to boost developer morale and create a more engaging CI/CD experience.
Code:
name: Developer Engagement
on: [push]
jobs:
engage:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Easter egg
if: env.CHANCE < 20
run: |
echo "Random chance passed ($CHANCE < 20)."
echo "Keep up the great work! You're doing amazing!"
Expected Outcome: Roughly 20% of runs display a positive or humorous message, adding a touch of delight to the developer experience without affecting workflow logic or performance.
Definition: Limit the frequency of high-cost operations (e.g., cloud-based integration tests, large dataset processing) by probabilistically skipping them.
Code:
name: Cost Control
on: [push]
jobs:
expensive_job:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Run expensive job
if: env.CHANCE < 10
run: |
echo "Running expensive job..."
./run-cloud-tests.sh
Expected Outcome: Expensive jobs are executed in only 10% of builds, reducing cloud resource usage and cost while still validating the full stack periodically.
Definition: Occasionally trigger a job that updates and tests the latest versions of dependencies to catch breaking changes early.
Code:
name: Dependency Freshness Check
on: [push]
jobs:
deps_check:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Update dependencies
if: env.CHANCE < 5
run: |
echo "Checking for dependency updates..."
npm update
npm test
Expected Outcome: Dependency updates are tested in 5% of builds, helping detect upstream changes without destabilizing the main workflow.
Definition: Introduce occasional enforcement of stricter linting or formatting rules to gradually improve code quality.
Code:
name: Linting Enforcement
on: [push]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Run strict linter
if: env.CHANCE < 10
run: |
echo "Running strict linting rules..."
eslint . --max-warnings=0
Expected Outcome: Stricter linting is enforced in 10% of builds, nudging the codebase toward higher quality without blocking all contributions.
Definition: Prompt contributors for feedback or survey participation in a small percentage of builds.
Code:
name: Feedback Prompt
on: [push]
jobs:
feedback:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set random chance
run: echo "CHANCE=$((RANDOM % 100))" >> $GITHUB_ENV
- name: Prompt for feedback
if: env.CHANCE < 5
run: |
echo "We value your feedback!"
echo "Please take a moment to fill out our developer experience survey: https://example.com/survey"
Expected Outcome: Feedback prompts appear in 5% of builds, enabling continuous improvement of developer tooling without being intrusive.