# GitHub Copilot Instructions for Bitwarden GitHub Actions
# Bitwarden GitHub Actions - Claude Code Configuration
## Repository Overview
This repository contains a collection of custom GitHub Actions used by Bitwarden to simplify and standardize CI/CD pipelines across their projects. The repository follows a modular structure where each action is self-contained in its own directory with its own `action.yml` file.
**Repository Details:**
- **Type**: GitHub Actions collection
- **Size**: Medium-sized repository with ~20 custom actions
@ -13,14 +14,17 @@ This repository contains a collection of custom GitHub Actions used by Bitwarden
@@ -13,14 +14,17 @@ This repository contains a collection of custom GitHub Actions used by Bitwarden
## Build and Validation Instructions
### Prerequisites
- Node.js (version 22+ for TypeScript actions)
- Python 3.13+ (for Python-based actions)
- Docker (for containerized actions)
### Initial Setup
1. **Always run `npm install` first** in the repository root to install development dependencies including Prettier, Husky, and lint-staged.
### Code Formatting and Linting
- **Code formatting**: This repository uses Prettier for all file types
- **Pre-commit hooks**: Husky is configured to run lint-staged on commit
@ -51,7 +55,9 @@ Refer to the [rules directory](https://github.com/bitwarden/workflow-linter/tree
@@ -51,7 +55,9 @@ Refer to the [rules directory](https://github.com/bitwarden/workflow-linter/tree
**Python requirement**: Python 3.13+ with `pip install bitwarden_workflow_linter`
### Testing Individual Actions
Each action has its own test workflow in `.github/workflows/test-*.yml`:
- `test-version-bump.yml` - Tests version bumping functionality
@ -61,7 +67,9 @@ Each action has its own test workflow in `.github/workflows/test-*.yml`:
@@ -61,7 +67,9 @@ Each action has its own test workflow in `.github/workflows/test-*.yml`:
**Test execution**: Tests run automatically on PRs affecting specific action directories.
### TypeScript Actions Build Process
For TypeScript-based actions (e.g., `get-keyvault-secrets`):
1. Source files are in `src/` directory
2. **Always run `npm run build`** or `tsc` to compile TypeScript to JavaScript
3. Compiled output goes to `lib/` directory
@ -69,7 +77,9 @@ For TypeScript-based actions (e.g., `get-keyvault-secrets`):
@@ -69,7 +77,9 @@ For TypeScript-based actions (e.g., `get-keyvault-secrets`):
5. **Critical**: Always commit both source AND compiled files
### Docker-based Actions
For containerized actions (e.g., `version-bump`, `get-checksum`):
- Use `Dockerfile` in action directory
- Python scripts use `main.py` as entry point
- **No local build required** - Docker builds during action execution
@ -77,6 +87,7 @@ For containerized actions (e.g., `version-bump`, `get-checksum`):
@@ -77,6 +87,7 @@ For containerized actions (e.g., `version-bump`, `get-checksum`):
- Use `@actions/core` for GitHub Actions integration
- `tsconfig.json` for TypeScript configuration
**Python Actions:**
- Main script typically named `main.py`
- Use environment variables for input (`os.getenv("INPUT_*")`)
- Docker-based execution via `Dockerfile`
**Testing:**
- Test workflows named `test-[action-name].yml`
- Test fixtures in `tests/fixtures/` subdirectories
- Tests validate action outputs and side effects
@ -169,6 +192,7 @@ For containerized actions (e.g., `version-bump`, `get-checksum`):
@@ -169,6 +192,7 @@ For containerized actions (e.g., `version-bump`, `get-checksum`):
All code changes and action development must follow security best practices relevant to GitHub Actions and Bitwarden's standards:
**GitHub Actions Security:**
- **No hard-coded secrets or credentials** - Use secure parameter passing
- **Validate all action inputs** - Sanitize and validate user-provided inputs to prevent injection attacks
- **Use pinned action versions** - All external actions must be pinned to specific commit hashes (enforced by workflow linter)
@ -176,16 +200,19 @@ All code changes and action development must follow security best practices rele
@@ -176,16 +200,19 @@ All code changes and action development must follow security best practices rele
- **Secure output handling** - Avoid exposing sensitive data in action outputs or logs
**Secret and Credential Management:**
- Use Azure Key Vault integration properly via `get-keyvault-secrets` action
- Never log or expose secret values in action outputs
- Use GitHub's secret masking capabilities (`core.setSecret()` in TypeScript actions)
**Supply Chain Security:**
- Only use approved actions listed in the workflow linter's approved actions list
- Pin all dependencies to specific versions in `package.json` and `requirements.txt`
- Validate Docker base images and use official, minimal images when possible
**Input Validation:**
- Validate file paths to prevent directory traversal attacks
- Sanitize version strings and other user inputs
- Use proper escaping when constructing shell commands
@ -195,6 +222,7 @@ All code changes and action development must follow security best practices rele
@@ -195,6 +222,7 @@ All code changes and action development must follow security best practices rele
**Trust these instructions** and only perform additional searching if the information provided is incomplete or found to be incorrect. The repository follows consistent patterns, and the validation processes are well-established.
**When making changes:**
1. Always format code with Prettier before committing
2. For TypeScript actions, always compile and commit the `lib/` output
3. Test changes using the existing test workflows when possible
@ -203,6 +231,7 @@ All code changes and action development must follow security best practices rele
@@ -203,6 +231,7 @@ All code changes and action development must follow security best practices rele
6. Apply security best practices and validate all inputs
**Common pitfalls to avoid:**
- Forgetting to compile TypeScript actions
- Not running Prettier formatting
- Missing required properties in `action.yml` files
This directory contains Claude Code configuration files for the gh-actions repository.
## Directory Structure
```
.claude/
├── CLAUDE.md # General project context and guidelines
├── commands/ # Custom slash commands
│ └── review-pr.md # /review-pr command for PR reviews
└── prompts/ # Workflow-specific prompts
└── review-code.md # Used by review-code.yml workflow
```
## Custom Commands
### `/review-pr` - Pull Request Review
Triggers a comprehensive PR code review in your current Claude Code session.
**Usage:**
1. Open Claude Code in this repository
2. Check out the PR branch you want to review
3. Tag @claude and type `/review-pr`
**What it does:**
- Analyzes code quality and best practices
- Checks for security vulnerabilities
- Validates workflow linter compliance
- Reviews performance and efficiency
- Provides structured feedback with action items
**Example:**
```
@claude /review-pr
```
## Automated Workflow Reviews
The `review-code.yml` workflow uses the `.claude/prompts/review-code.md` to automatically review PRs via GitHub Actions in each Bitwarden repo. The `review-code.md` is used as a gate to execute the `review-code.yml` workflow. Repos without this file will not see Claude code reviews performed on each pull request.
**How it works:**
1. Workflow triggers on non-draft PRs
2. Reads `.claude/prompts/review-code.md` from the PR's branch
3. Posts review as a sticky comment
4. Updates comment on new commits
**To enable in our repos:**
1. Create `.claude/prompts/review-code.md` with review criteria
2. Workflow runs automatically on subsequent pull requests
## Best Practices
- **Commands** (`.claude/commands/`): For interactive Claude Code sessions
- **Prompts** (`.claude/prompts/`): For automated GitHub Actions workflows
- **CLAUDE.md**: General project context available in all Claude interactions
Note: The PR branch is already checked out in the current working directory.
Provide a comprehensive review including:
- Summary of changes since last review
- Critical issues found (be thorough)
- Suggested improvements (be thorough)
- Good practices observed (be concise - list only the most notable items without elaboration)
- Action items for the author
- Leverage collapsible <details> sections where appropriate for lengthy explanations or code snippets to enhance human readability
When reviewing subsequent commits:
- Track status of previously identified issues (fixed/unfixed/reopened)
- Identify NEW problems introduced since last review
- Note if fixes introduced new issues
IMPORTANT: Be comprehensive about issues and improvements. For good practices, be brief - just note what was done well without explaining why or praising excessively.