Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions .plugin/marketplace.json
Original file line number Diff line number Diff line change
Expand Up @@ -166,6 +166,19 @@
"workflows"
]
},
{
"name": "github-actions",
"source": "./github-actions",
"description": "Create, debug, and test GitHub Actions workflows and custom actions. Use when building CI/CD pipelines, automating workflows, or troubleshooting GitHub Actions.",
"category": "integration",
"keywords": [
"github-actions",
"workflows",
"ci-cd",
"automation",
"actions"
]
},
{
"name": "github-pr-review",
"source": "./github-pr-review",
Expand Down
34 changes: 34 additions & 0 deletions skills/github-actions/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# GitHub Actions Skill

A comprehensive skill for creating, debugging, and testing GitHub Actions workflows and custom actions.

## Overview
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Expand README with the practical "how-to" content currently in SKILL.md lines 25-70 (debugging workflows, command examples, troubleshooting patterns). README should be the detailed guide, SKILL.md should be the decision criteria.


This skill provides guidance for working with GitHub Actions, including:
- Creating and structuring workflows
- Building custom actions (composite and reusable)
- Testing actions locally and in CI
- Debugging failed workflows
- Avoiding common pitfalls
- Best practices and security considerations

## When to Use This Skill

Use this skill when:
- Creating new GitHub Actions workflows
- Building custom composite or reusable actions
- Debugging workflow failures
- Setting up CI/CD pipelines
- Troubleshooting permission or secret issues
- Testing actions before merging to main

## Best Practices

1. **Pin action versions**: Use specific versions (`@v4`) or SHA hashes, not `@main`
2. **Minimal permissions**: Explicitly set `permissions` to minimum required
3. **Debug steps**: Add debug output when creating new actions or troubleshooting tricky issues (not required for every workflow)
4. **Fail fast**: Use `fail-fast: false` in matrix builds only when needed
5. **Secrets handling**: Never print secrets; they're masked but can be exposed via encoding
6. **Caching**: Use `actions/cache` for dependencies to speed up workflows
7. **Concurrency control**: Use `concurrency` to cancel redundant workflow runs
8. **Timeout limits**: Set `timeout-minutes` to prevent hung jobs
78 changes: 78 additions & 0 deletions skills/github-actions/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
---
name: github-actions
description: Create, debug, and test GitHub Actions workflows and custom actions. Use when building CI/CD pipelines, automating workflows, or troubleshooting GitHub Actions.
triggers:
- github actions
- workflow
- ci/cd
- github workflow
---

# GitHub Actions Guide

## Critical Rules

**Custom Action Deployment:**
- New custom actions MUST be merged to the main branch before they can be used
- After the initial merge, should tested from feature branches
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Grammar error - "should tested" → "should be tested"


**Debug Steps:**
Add debug steps that print non-secret parameters when:
- Creating a new action, OR
- Troubleshooting a particularly tricky issue

(Not required for every workflow - use when needed)

## Testing & Monitoring Strategy

**Actions have costs** - Each workflow run consumes CI minutes. Plan efficiently:

1. **Use debug steps early** - don't guess, read actual values
2. **Monitor actively** - use `gh run watch <run-id>` or `gh pr checks <pr-number> --watch`
3. **Read logs immediately** - `gh run view <run-id> --log` or view in GitHub UI
4. **Understand before changing** - examine what actually ran, not what you think ran

**Effective debugging workflow:**
```bash
# Watch workflow run in real-time
gh run watch

# Or monitor PR checks with auto-refresh
gh pr checks <pr-number> --watch --interval 10

# When failed, read full logs immediately
gh run view <run-id> --log

# Examine specific job logs
gh run view <run-id> --log --job=<job-id>
```

**Add visibility to your actions:**
```yaml
steps:
# Print all non-secret inputs/context at start
- name: Debug - Action inputs
run: |
echo "Event: ${{ github.event_name }}"
echo "Ref: ${{ github.ref }}"
echo "Actor: ${{ github.actor }}"
echo "Working dir: $(pwd)"
echo "Custom input: ${{ inputs.my-param }}"

# Your action logic here

# Verify outcome before finishing
- name: Debug - Verify results
run: |
echo "Files created:"
ls -la
echo "Exit code: $?"
```
Comment on lines +25 to +70
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion - Progressive Disclosure: This 46-line section is tutorial content (bash commands, debugging workflows, YAML examples). Previous reviews said this belongs in README.md. Move it there under "Debugging Workflows" and keep SKILL.md focused on decision criteria (~30-40 lines total).


## Key Gotchas

1. **Secrets unavailable in fork PRs** - Use `pull_request_target` with caution or don't rely on secrets
2. **Pin action versions** - Use `@v4` or SHA, not `@main` (prevents breaking changes)
3. **Explicit permissions** - Set `permissions:` block for GITHUB_TOKEN operations
4. **Artifacts for job-to-job data** - Files don't persist between jobs without `upload-artifact`/`download-artifact`

Loading