ci-cd-and-automation
Skill2 starsChanged 41 days agoMITView on GitHub
Use when setting up or improving CI/CD pipelines for Android. Covers sequential quality gates, Gradle caching, emulator testing in CI, feature flags, and automated deployment to Play Store.
67 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- ishandutta2007/Awesome-Agent-Skillstheir own version, first seen Nov 8, 2026
- TheAstroByte/astrobyte-agent-skillstheir own version, first seen Nov 8, 2026
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- steven123397/nexuskit-skillstheir own version, first seen Nov 1, 2026
- yuusakuri/agent-skillstheir own version, first seen Nov 1, 2026
- lza6/claw-code-tingfengtheir own version, first seen Nov 1, 2026
Used with
Projects with it also use minimalist-ui, redesign-existing-projects and 3 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AnasX7Skillminimalist-ui
Clean editorial-style interfaces. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.
Also in 3 projects that use this
AnasX7Skillredesign-existing-projects
Upgrades existing websites and apps to premium quality. Audits current design, identifies generic AI patterns, and applies high-end design standards without breaking functionality. Works with any CSS framework or vanilla CSS.
Also in 3 projects that use this
OpenAISkillverification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Also in 5 projects that use this
MicrosoftSkillplaywright-cli
Automate browser interactions, test web pages and work with Playwright tests.
Also in 4 projects that use this
VercelSkillweb-design-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
Also in 5 projects that use this
Other versions67 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- viasrijan/crazy-skills★ 010% same
Wrote their own version · 66
- addyosmani/agent-skills★ 114ksame name
- ollaya-dev/ollaya★ 1.4ksame name
- shashankswe2020-ux/whoop-mcp★ 174same name
- vinvcn/addyosmani-agent-skills-zh★ 46same name
- jmxt3/gitscape.ai★ 33same name
- sampleXbro/agentsmesh★ 27same name
- jaskirat1616/grok-skills★ 22same name
- ishandutta2007/Awesome-Agent-Skills★ 21same name
- JPeetz/agent-skills★ 14same name
- CrowPus/Zelyq★ 10same name
56 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository31 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- android-accessibilitySkill
- android-architectureSkill
- android-background-workSkill
- android-data-persistenceSkill
- android-device-testingSkill
- android-e2e-verificationSkill
- android-ui-engineeringSkill
- api-and-interface-designSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- constraint-driven-developmentSkill
- context-engineeringSkill
- debugging-and-error-recoverySkill
- deprecation-and-migrationSkill
- documentation-and-adrsSkill
- doubt-driven-developmentSkill
- git-workflow-and-versioningSkill
- idea-refineSkill
- incremental-implementationSkill
- interview-meSkill
- observability-and-instrumentationSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- security-and-hardeningSkill
- shipping-and-launchSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- test-driven-developmentSkill
- using-agent-skillsSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 64 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 182
If the repo has committed Maestro flows (.maestro/), run them in the same emulator job after installing the debug build — ./gradlew …
- Very specific: line 184
When the android CLI is present in the runner image, android sdk install is a leaner alternative to setup-android for declarative …
- Distinctive: line 292
Read the failure output
- Distinctive: line 296
If the fix introduces new failures, revert and investigate
- Distinctive: line 329
No Gradle caching in CI
“Common” is measured: kept by at least 6 in 10 of the 64 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CI/CD and Automation
Overview
Shift left: catch problems early through automated checks. A well-structured CI pipeline runs sequential quality gates — from fast checks (lint, compile) to slow checks (instrumented tests, security audit) — so feedback arrives quickly and issues are caught before merging.
When to Use
- Setting up CI for a new Android project
- Adding quality gates to an existing pipeline
- CI pipeline exceeds 10 minutes (needs optimization)
- Automating deployment to Play Store or Firebase App Distribution
- Feature flag management for staged rollouts
Skip when: The project has no CI (start with ci-cd-and-automation first).
Core Process
Step 1: Sequential Quality Gates
- Gate order (fastest to slowest):
# .github/workflows/android-ci.yml
name: Android CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
lint-and-compile:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- name: Setup Gradle
uses: gradle/actions/setup-gradle@v4
# Gate 1: Format check (~30s)
- name: Check formatting
run: ./gradlew spotlessCheck
# Gate 2: Static analysis (~1min)
- name: Run detekt
run: ./gradlew detekt
# Gate 3: Compile (~2min)
- name: Compile
run: ./gradlew assembleDebug
# Gate 4: Android Lint (~3min)
- name: Lint
run: ./gradlew lint
unit-tests:
needs: lint-and-compile
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- uses: gradle/actions/setup-gradle@v4
# Gate 5: Unit tests (~3min)
- name: Unit tests
run: ./gradlew test
- name: Upload test results
if: always()
uses: actions/upload-artifact@v4
with:
name: test-results
path: '**/build/reports/tests/'
instrumented-tests:
needs: unit-tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
# Gate 6: Instrumented tests (~10min)
- name: Run instrumented tests
uses: reactivecircus/android-emulator-runner@v2
with:
api-level: 36 # Play target floor; add API 37 to the matrix for latest-behavior testing
arch: x86_64
script: ./gradlew connectedAndroidTest
security-check:
needs: unit-tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# Gate 7: Dependency vulnerability scan
- name: Security audit
run: ./gradlew dependencyCheckAnalyze
# Gate 8: Secrets scan
- name: Check for secrets
uses: trufflesecurity/trufflehog@main
with:
extra_args: --only-verified- No gate skipping — fix the code, don't disable the rule:
// BAD: suppressing lint
@Suppress("MagicNumber")
val timeout = 5000
// GOOD: use a named constant
private const val NETWORK_TIMEOUT_MS = 5_000LStep 2: Gradle Caching
- Cache Gradle dependencies and build outputs:
# Gradle caching is handled by gradle/actions/setup-gradle@v4
# It automatically caches:
# - ~/.gradle/caches
# - ~/.gradle/wrapper
# - .gradle (project-level)
# - Build outputs
- uses: gradle/actions/setup-gradle@v4
with:
cache-read-only: ${{ github.event_name == 'pull_request' }}- Gradle build optimization:
# gradle.properties
org.gradle.caching=true
org.gradle.parallel=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx4g -XX:+UseParallelGCStep 3: Emulator Testing in CI
- Use
android-emulator-runnerfor instrumented tests:
- name: Run instrumented tests
uses: reactivecircus/android-emulator-runner@v2
with:
api-level: 36
arch: x86_64
target: google_apis
profile: pixel_6
emulator-options: -no-snapshot-save -no-window -gpu swiftshader_indirect -noaudio
disable-animations: true
script: ./gradlew connectedAndroidTestIf the repo has committed Maestro flows (.maestro/), run them in the same emulator job after installing the debug build — ./gradlew installDebug && maestro test .maestro/ — so every shipped acceptance criterion is regression-checked per PR (see android-e2e-verification).
When the android CLI is present in the runner image, android sdk install is a leaner alternative to setup-android for declarative platform/build-tools provisioning:
- name: Install Android platforms
run: |
android sdk install \
platforms/android-35 \
build-tools/35.0.0 \
platform-toolsStick with reactivecircus/android-emulator-runner for the emulator itself — android emulator is disabled on Windows and the runner action handles snapshot caching, hardware acceleration, and animation disabling that you'd otherwise rebuild by hand. See ../../references/android-cli-reference.md.
- Test sharding for large test suites:
strategy:
matrix:
shard: [0, 1, 2, 3]
steps:
- name: Run tests (shard ${{ matrix.shard }})
run: |
./gradlew connectedAndroidTest \
-Pandroid.testInstrumentationRunnerArguments.numShards=4 \
-Pandroid.testInstrumentationRunnerArguments.shardIndex=${{ matrix.shard }}Step 4: Feature Flags
- Decouple deployment from release:
// Build-time flags (for CI/staging)
// build.gradle.kts
android {
buildTypes {
debug {
buildConfigField("Boolean", "FEATURE_NEW_UI", "true")
}
release {
buildConfigField("Boolean", "FEATURE_NEW_UI", "false")
}
}
}
// Runtime flags (for gradual rollout)
// Using Firebase Remote Config
class FeatureFlagRepository @Inject constructor(
private val remoteConfig: FirebaseRemoteConfig,
) {
fun isEnabled(key: String): Flow<Boolean> = callbackFlow {
val listener = ConfigUpdateListener { trySend(remoteConfig.getBoolean(key)) }
remoteConfig.addOnConfigUpdateListener(listener)
trySend(remoteConfig.getBoolean(key))
awaitClose { /* cleanup */ }
}
}Step 5: Deployment Automation
- Firebase App Distribution (internal testing):
deploy-internal:
needs: [unit-tests, instrumented-tests, security-check]
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- name: Build release APK
run: ./gradlew assembleRelease
- name: Upload to Firebase App Distribution
uses: wzieba/Firebase-Distribution-Github-Action@v1
with:
appId: ${{ secrets.FIREBASE_APP_ID }}
serviceCredentialsFileContent: ${{ secrets.FIREBASE_CREDENTIALS }}
groups: internal-testers
file: app/build/outputs/apk/release/app-release.apk- Play Store (production):
deploy-production:
needs: [deploy-internal] # After internal testing
if: startsWith(github.ref, 'refs/tags/v')
runs-on: ubuntu-latest
steps:
- name: Upload to Play Store
uses: r0adkll/upload-google-play@v1
with:
serviceAccountJsonPlainText: ${{ secrets.PLAY_STORE_CREDENTIALS }}
packageName: com.example.app
releaseFiles: app/build/outputs/bundle/release/app-release.aab
track: internal # internal → alpha → beta → production
status: completedStep 6: Feedback Loops
- When CI fails, use the agent feedback loop:
- Read the failure output
- Identify the gate that failed
- Fix the specific issue (don't disable the gate)
- Re-run the pipeline
- If the fix introduces new failures, revert and investigate
Step 7: Pipeline Optimization
- If pipeline exceeds 10 minutes:
- Cache dependencies (Gradle, SDK components)
- Parallelize independent gates (lint + unit tests simultaneously)
- Selective testing (only run affected modules)
- Test sharding (split instrumented tests across emulators)
- Build cache (enable Gradle build cache)
Environment Separation
| Environment | Secrets Source | Build Type |
| Local | local.properties (gitignored) | Debug |
| CI | GitHub Secrets / Vault | Debug + Release |
| Staging | Firebase Remote Config | Release (staging flavor) |
| Production | Play Store + Firebase | Release |
Common Rationalizations
| Shortcut | Why It Fails |
| "CI is too slow, I'll push without waiting" | Pushing broken code blocks the team. Optimize the pipeline instead. |
| "Lint warnings aren't real errors" | Lint catches real bugs (unused resources, API compatibility, security issues). |
| "Instrumented tests are too flaky for CI" | Flaky tests have root causes. Fix them or isolate them — don't skip them. |
| "We'll add CI later" | Later means tech debt. Start with lint + compile + unit tests on day one. |
Red Flags
- No CI pipeline
- CI gates disabled or skipped (
@Suppress,-x lint) - No Gradle caching in CI
- Instrumented tests not running in CI
- Secrets in repository (use GitHub Secrets)
- No deployment automation
- Pipeline exceeds 15 minutes without optimization
- Feature flags without cleanup plan
Verification
- CI runs on every PR and push to main
- Gates run in order: format → lint → compile → unit tests → instrumented tests → security
- No gates skipped or disabled
- Gradle caching configured
- Instrumented tests run on emulator in CI
- Secrets stored in CI environment (not in repo)
- Deployment automated (Firebase App Distribution and/or Play Store)
- Pipeline completes in < 15 minutes
- Failed gates produce actionable error messages
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

