# GitHub Copilot Instructions for Bitwarden GitHub Actions
# Bitwarden GitHub Actions - Claude Code Configuration
## Repository Overview
## 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.
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:**
**Repository Details:**
- **Type**: GitHub Actions collection
- **Type**: GitHub Actions collection
- **Size**: Medium-sized repository with ~20 custom actions
- **Size**: Medium-sized repository with ~20 custom actions
- Use `@actions/core` for GitHub Actions integration
- Use `@actions/core` for GitHub Actions integration
- `tsconfig.json` for TypeScript configuration
- `tsconfig.json` for TypeScript configuration
**Python Actions:**
**Python Actions:**
- Main script typically named `main.py`
- Main script typically named `main.py`
- Use environment variables for input (`os.getenv("INPUT_*")`)
- Use environment variables for input (`os.getenv("INPUT_*")`)
- Docker-based execution via `Dockerfile`
- Docker-based execution via `Dockerfile`
**Testing:**
**Testing:**
- Test workflows named `test-[action-name].yml`
- Test workflows named `test-[action-name].yml`
- Test fixtures in `tests/fixtures/` subdirectories
- Test fixtures in `tests/fixtures/` subdirectories
- Tests validate action outputs and side effects
- Tests validate action outputs and side effects
@ -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:
All code changes and action development must follow security best practices relevant to GitHub Actions and Bitwarden's standards:
**GitHub Actions Security:**
**GitHub Actions Security:**
- **No hard-coded secrets or credentials** - Use secure parameter passing
- **No hard-coded secrets or credentials** - Use secure parameter passing
- **Validate all action inputs** - Sanitize and validate user-provided inputs to prevent injection attacks
- **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)
- **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
- **Secure output handling** - Avoid exposing sensitive data in action outputs or logs
- **Secure output handling** - Avoid exposing sensitive data in action outputs or logs
**Secret and Credential Management:**
**Secret and Credential Management:**
- Use Azure Key Vault integration properly via `get-keyvault-secrets` action
- Use Azure Key Vault integration properly via `get-keyvault-secrets` action
- Never log or expose secret values in action outputs
- Never log or expose secret values in action outputs
- Use GitHub's secret masking capabilities (`core.setSecret()` in TypeScript actions)
- Use GitHub's secret masking capabilities (`core.setSecret()` in TypeScript actions)
**Supply Chain Security:**
**Supply Chain Security:**
- Only use approved actions listed in the workflow linter's approved actions list
- 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`
- Pin all dependencies to specific versions in `package.json` and `requirements.txt`
- Validate Docker base images and use official, minimal images when possible
- Validate Docker base images and use official, minimal images when possible
**Input Validation:**
**Input Validation:**
- Validate file paths to prevent directory traversal attacks
- Validate file paths to prevent directory traversal attacks
- Sanitize version strings and other user inputs
- Sanitize version strings and other user inputs
- Use proper escaping when constructing shell commands
- Use proper escaping when constructing shell commands
@ -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.
**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:**
**When making changes:**
1. Always format code with Prettier before committing
1. Always format code with Prettier before committing
2. For TypeScript actions, always compile and commit the `lib/` output
2. For TypeScript actions, always compile and commit the `lib/` output
3. Test changes using the existing test workflows when possible
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
6. Apply security best practices and validate all inputs
6. Apply security best practices and validate all inputs
**Common pitfalls to avoid:**
**Common pitfalls to avoid:**
- Forgetting to compile TypeScript actions
- Forgetting to compile TypeScript actions
- Not running Prettier formatting
- Not running Prettier formatting
- Missing required properties in `action.yml` files
- 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.
Amy Galles
2 months ago