Skip to content

Commit 32e2093

Browse files
chmouelpipelines-as-code[bot]
chmouel
authored and
pipelines-as-code[bot]
committed
feat: Implement comprehensive development rules for Cursor
* Established comprehensive project development guidelines for Cursor AI. * Defined rules for code architecture, formatting, and dependency management. * Set standards for documentation and various testing methodologies. * Introduced pre-commit hooks and project quality gates. * Included a detailed specification for Git commit message adherence. * Provided a quick reference for common development commands. * Configured Cursor AI to utilize the newly added rules. * Adjusted markdown linting configuration for new rules. Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
1 parent ecd0637 commit 32e2093

11 files changed

+251
-6
lines changed

‎.cursor/rules/architecture.mdc

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
description: Architecture and Targets
3+
alwaysApply: false
4+
---
5+
# Architecture and Targets
6+
7+
- The project targets both arm64 and amd64 architectures
8+
- Use `ko` for building container images in development
9+
- The project uses Tekton pipelines and integrates with multiple Git providers (GitHub, GitLab, Bitbucket, Gitea)

‎.cursor/rules/code-formatting.mdc

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
description: Code formatting rules for the project.
3+
alwaysApply: false
4+
---
5+
# Code Quality and Formatting
6+
7+
- Always run `make fumpt` after writing Go code to ensure proper formatting
8+
- Use `make fix-linters` to automatically fix most linting issues
9+
- Run `make check` to verify both linting and tests pass before committing
10+
- For markdown files, use `make fix-markdownlint` to fix formatting issues
11+
- Use `make fix-trailing-spaces` to clean up trailing whitespace in markdown and yaml files

‎.cursor/rules/dependencies.mdc

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
description: Dependencies and Modules
3+
alwaysApply: false
4+
---
5+
# Dependencies and Modules
6+
7+
- Always run `make vendor` after adding new dependencies
8+
- Check for and remove unnecessary `replace` clauses in go.mod
9+
- Update Go version to match the latest RHEL version when needed
10+
- Use `go mod tidy -go=1.20` (or appropriate version) to update Go version

‎.cursor/rules/documentation.mdc

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
description: Writting documentation
3+
alwaysApply: false
4+
---
5+
# Documentation
6+
7+
- Use `make dev-docs` to preview documentation changes locally at <http://localhost:1313>
8+
- Documentation uses Hugo with the hugo-book theme
9+
- Use the custom shortcodes like `tech_preview` and `support_matrix` for feature documentation
10+
- Follow the documentation guidelines in the developer docs

‎.cursor/rules/e2e-testing.mdc

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
description: E2E testing rules
3+
alwaysApply: false
4+
---
5+
# E2E Testing
6+
7+
- Always ask the user to run the e2e tests manually and copy the output. Since
8+
E2E tests require specific setup and environment variables
9+
- Gitea tests are the most comprehensive and self-contained

‎.cursor/rules/git-commit-format.mdc

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
---
2+
description: Git commit message formatting rules, for use when generating commit messages
3+
alwaysApply: false
4+
---
5+
# Commit Message Formatting Rules
6+
7+
**When to apply**: When generating commit messages or discussing commit practices
8+
9+
**Description**: Rules for formatting commit messages with conventional commits and Jira issue integration
10+
11+
## Commit Message Format
12+
13+
Use conventional commits format:
14+
15+
```
16+
<type>(<scope>): <description>
17+
18+
[optional body]
19+
20+
Signed-off-by: <name> <email>
21+
Assisted-by: <model-name> (via Cursor)
22+
```
23+
24+
## Line Length Requirements
25+
26+
Follow conventional commit line length standards:
27+
28+
- **Subject line**: Maximum 50 characters (hard limit: 72 characters)
29+
- **Body**: Wrap at 72 characters per line
30+
- **Blank line**: Always include blank line between subject and body
31+
- **Footer**: Each footer on separate line
32+
33+
## Scope Rules
34+
35+
1. **For branches with Jira issues** (pattern: `SRVKP-XXX-description` or `OCP-XXX-description`):
36+
- Extract Jira issue number using regex: `[A-Z]{2,}-[0-9]+`
37+
- Use as scope: `feat(SRVKP-123): description`
38+
39+
2. **For main/master branches or non-Jira branches**:
40+
- Ask user for Jira issue number
41+
- Look up issue on issues.redhat.com using web search
42+
- Use component name as fallback: `feat(webhook)`, `fix(controller)`, `docs(README)`
43+
44+
## Commit Types
45+
46+
- **feat**: New features
47+
- **fix**: Bug fixes
48+
- **docs**: Documentation changes
49+
- **style**: Code style changes
50+
- **refactor**: Code refactoring
51+
- **test**: Adding/updating tests
52+
- **chore**: Maintenance tasks
53+
- **build**: Build system or dependencies
54+
- **ci**: CI/CD changes
55+
- **perf**: Performance improvements
56+
- **revert**: Revert previous commit
57+
58+
## Required Footers
59+
60+
### Signed-off-by
61+
62+
- Always include: `Signed-off-by: <name> <email>`
63+
- Get name and email using this priority order:
64+
1. Environment variables: `$GIT_AUTHOR_NAME` and `$GIT_AUTHOR_EMAIL`
65+
2. Git config: `git config user.name` and `git config user.email`
66+
3. If neither configured, ask user to provide details
67+
- Common in dev containers: environment variables are preferred method
68+
69+
### Assisted-by
70+
71+
- Always include: `Assisted-by: <model-name> (via Cursor)`
72+
- Format examples:
73+
- `Assisted-by: Claude-3.5-Sonnet (via Cursor)`
74+
- `Assisted-by: Gemini (via Cursor)`
75+
- Use the actual model name being used for the commit message generation
76+
77+
## Examples
78+
79+
```bash
80+
feat(SRVKP-123): Add webhook controller for GitHub integration
81+
82+
Signed-off-by: Developer Name <developer@redhat.com>
83+
Assisted-by: Claude-3.5-Sonnet (via Cursor)
84+
```
85+
86+
```bash
87+
fix(controller): Update pipeline reconciliation logic
88+
89+
Resolves issue with concurrent pipeline runs
90+
91+
Signed-off-by: Developer Name <developer@redhat.com>
92+
Assisted-by: Claude-3.5-Sonnet (via Cursor)
93+
```
94+
95+
## Auto-Detection Rules
96+
97+
When generating commit messages:
98+
99+
1. Check current branch name for Jira issue pattern
100+
2. If no Jira issue in branch, ask user for issue number
101+
3. Look up issue details on issues.redhat.com if provided
102+
4. Analyze staged files to determine commit type
103+
5. Generate appropriate scope and description
104+
6. Detect author info from environment variables ($GIT_AUTHOR_NAME, $GIT_AUTHOR_EMAIL) or git config
105+
7. Ensure subject line is ≤50 characters (max 72 characters)
106+
8. Wrap body text at 72 characters per line
107+
9. Add required footers (Signed-off-by and Assisted-by)
108+
10. Format according to conventional commits standard
109+
110+
## Commit Process
111+
112+
**IMPORTANT**: Always ask for user confirmation before executing `git commit`:
113+
114+
1. **Generate** the commit message following the rules above
115+
2. **Display** the generated commit message to the user
116+
3. **Ask for confirmation**: "Should I commit with this message? (y/n)"
117+
4. **Wait for user response** before running `git commit`
118+
5. **Only commit** if user confirms with "yes", "y", or similar affirmative response
119+
120+
**Example interaction:**
121+
122+
```
123+
Generated commit message:
124+
---
125+
feat(SRVKP-456): ensure webhook logs output to stdout
126+
127+
Configure webhook controller to direct all logs to stdout for container compatibility
128+
129+
Signed-off-by: Developer Name <developer@redhat.com>
130+
Assisted-by: Claude-3.5-Sonnet (via Cursor)
131+
---
132+
133+
Should I commit with this message? (y/n)
134+
```
135+
136+
## Jira Issue Lookup Process
137+
138+
When no Jira issue is found in branch name:
139+
140+
1. Ask user: "What Jira issue number should I use for this commit?"
141+
2. If provided, search issues.redhat.com for issue details
142+
3. Use issue summary and description to enhance commit message
143+
4. Suggest creating a new branch if desired
144+
145+
## Gitlint Integration
146+
147+
- The project uses gitlint to enforce commit message format
148+
- Ensure all commit messages pass gitlint validation
149+
- Common gitlint rules to follow:
150+
- Conventional commit format
151+
- Proper line length limits
152+
- Required footers
153+
- No trailing whitespace

‎.cursor/rules/pre-commit.mdc

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
description: Pre-commit and Quality Gates
3+
alwaysApply: false
4+
---
5+
- Install pre-commit hooks with `pre-commit install` to ensure code quality
6+
- The project uses multiple linters: golangci-lint, yamllint, markdownlint, ruff, shellcheck, vale, codespell
7+
- Pre-commit hooks run automatically on push, but can be skipped with `git push --no-verify`
8+
- Use `SKIP=hook-name git push` to skip specific hooks
9+

‎.cursor/rules/testing-quality.mdc

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
---
2+
description: Testing and Quality Assurance
3+
alwaysApply: false
4+
---
5+
6+
- if you need to run test, run the test with `make test`
7+
- if you need to run the linter, run the linter with `make lint`
8+
- every time you write go code, make sure to run `make fumpt` to reformat the code
9+
- every time you write markdown make sure to do a `make fix-markdownlint` to fix the markdown
10+
- if you need to add a dependency, use `go get -u dependency` and make sure to run `make vendor` afterwards or it would not work.
11+
- do not try to run the e2e tests in tests/ there is a bunch of pre-requisites
12+
that need to be set up. Ask the user to run the e2e tests manually and copy the
13+
output.
14+
- When writing unit tests, always use `gotest.tools/v3` and never use other libraries like testify

‎.cursor/rules/useful-commands.mdc

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
---
2+
description: Useful commands for building and testing the project.
3+
alwaysApply: false
4+
---
5+
6+
- `make help` - Show all available make targets
7+
- `make all` - Build all binaries, run tests and lint
8+
- `make html-coverage` - Generate HTML test coverage report
9+
- `make test-no-cache` - Run tests without caching
10+
- `make clean` - Clean build artifacts
11+
12+
# Useful Commands
13+
14+
- `make help` - Show all available make targets
15+
- `make all` - Build all binaries, run tests and lint
16+
- `make html-coverage` - Generate HTML test coverage report
17+
- `make test-no-cache` - Run tests without caching
18+
- `make clean` - Clean build artifacts

‎.markdownlint.json

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,9 @@
11
{
2-
"line-length": false,
3-
"first-header-h1": false,
4-
"no-inline-html": false,
5-
"MD013": false,
6-
"MD025": false,
7-
"descriptive-link-text": false
2+
"line-length": false,
3+
"first-header-h1": false,
4+
"first-line-h1": false,
5+
"no-inline-html": false,
6+
"MD013": false,
7+
"MD025": false,
8+
"descriptive-link-text": false
89
}

0 commit comments

Comments
 (0)