Skip to content

Commit 2fb6740

Browse files
chmouelchmouel
authored
Merge branch 'main' into refactor-improve-github-app-installation-id-retrie
2 parents e8fb002 + fdd6549 commit 2fb6740

File tree

74 files changed

+1657
-546
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

74 files changed

+1657
-546
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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

‎.github/pull_request_template.md

Lines changed: 33 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,30 +1,50 @@
1-
# Changes <!-- 🎉🎉🎉 Thank you for the PR!!! 🎉🎉🎉 -->
1+
## 📝 Description of the Change
22

3-
<!-- Describe your changes here- ideally you can get that description straight from your descriptive commit message(s)! -->
3+
<!--- Take all comments into account and provide a detailed description of the change. -->
44

5-
# Submitter Checklist
5+
## 🔗 Linked GitHub Issue
66

7-
- [ ] 📝 Ensure your commit message is clear and informative. Refer to the How to write a git commit message guide. Include the commit message in the PR body rather than linking to an external site (e.g., Jira ticket).
7+
Fixes #
88

9-
- [ ] ♽ Run make test lint before submitting a PR to avoid unnecessary CI processing. Consider installing [pre-commit](https://pre-commit.com/) and running pre-commit install in the repository root for an efficient workflow.
9+
## 👨🏻‍ Linked Jira
1010

11-
- [ ] ✨ We use linters to maintain clean and consistent code. Run make lint before submitting a PR. Some linters offer a --fix mode, executable with make fix-linters (ensure [markdownlint](https://github.com/DavidAnson/markdownlint) and [golangci-lint](https://github.com/golangci/golangci-lint) are installed).
11+
<!-- This is optional, but if you have a Jira ticket related to this PR, please link it here. -->
12+
## 🚀 Type of Change
1213

13-
- [ ] 📖 Document any user-facing features or changes in behavior.
14+
- [ ] 🐛 Bug fix (`fix:`)
15+
- [ ] ✨ New feature (`feat:`)
16+
- [ ] 💥 Breaking change (`feat!:`, `fix!:`)
17+
- [ ] 📚 Documentation update (`docs:`)
18+
- [ ] ⚙️ Chore (`chore:`)
19+
- [ ] 💅 Refactor (`refactor:`)
20+
- [ ] 🔧 Enhancement (`enhance:`)
1421

15-
- [ ] 🧪 While 100% coverage isn't required, we encourage unit tests for code changes where possible.
22+
<!-- (update the title of the Pull Request accordingly) -->
1623

17-
- [ ] 🎁 If feasible, add an end-to-end test. See [README](https://github.com/openshift-pipelines/pipelines-as-code/blob/main/test/README.md) for details.
24+
## 🧪 Testing Strategy
1825

19-
- [ ] 🔎 Address any CI test flakiness before merging, or provide a valid reason to bypass it (e.g., token rate limitations).
26+
- [ ] Unit tests
27+
- [ ] Integration tests
28+
- [ ] End-to-end tests
29+
- [ ] Manual testing
30+
- [ ] Not Applicable
2031

21-
- If adding a provider feature, fill in the following details:
32+
## ✅ Submitter Checklist
2233

34+
- [ ] 📝 My commit messages are clear, informative, and follow the project's [How to write a git commit message guide](https://developers.google.com/blockly/guides/contribute/get-started/commits). **The [Gitlint](https://jorisroovers.com/gitlint/latest) linter ensures in CI it's properly validated**
35+
- [ ] ✨ I have ensured my commit message prefix (e.g., `fix:`, `feat:`) matches the "Type of Change" I selected above.
36+
- [ ] ♽ I have run `make test` and `make lint` locally to check for and fix any
37+
issues. For an efficient workflow, I have considered installing
38+
[pre-commit](https://pre-commit.com/) and running `pre-commit install` to
39+
automate these checks.
40+
- [ ] 📖 I have added or updated documentation for any user-facing changes.
41+
- [ ] 🧪 I have added sufficient unit tests for my code changes.
42+
- [ ] 🎁 I have added end-to-end tests where feasible. See [README](https://github.com/openshift-pipelines/pipelines-as-code/blob/main/test/README.md) for more details.
43+
- [ ] 🔎 I have addressed any CI test flakiness or provided a clear reason to bypass it.
44+
- [ ] If adding a provider feature, I have filled in the following and updated the provider documentation:
2345
- [ ] GitHub App
2446
- [ ] GitHub Webhook
2547
- [ ] Gitea/Forgejo
2648
- [ ] GitLab
2749
- [ ] Bitbucket Cloud
2850
- [ ] Bitbucket Data Center
29-
30-
(update the provider documentation accordingly)

0 commit comments

Comments
 (0)