Add issue and PR templates, CI workflows, and automation scripts#284
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request adds GitHub project automation infrastructure including issue/PR templates and automated workflows for labeling, assignment, and continuous integration. The changes aim to standardize contributions and improve project maintenance workflows for the Open Elements website repository.
Changes:
- Added structured YAML-based issue templates for bug reports and feature requests with validation and auto-labeling
- Introduced PR template with checklist to ensure complete PR submissions
- Added automated workflows for PR labeling based on changed files and issue classification
- Implemented a CI workflow for running lint, type-check, test, and build tasks
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 14 comments.
Show a summary per file
| File | Description |
|---|---|
| .github/workflows/pr-automation.yml | Automates PR labeling based on file types and assigns PR to author |
| .github/workflows/issue-automation.yml | Auto-labels issues as bugs or enhancements and assigns to maintainer |
| .github/workflows/ci.yml | Runs linting, type-checking, testing, and building on pushes and PRs |
| .github/pull_request_template.md | Provides structured PR template with type selection and checklist |
| .github/ISSUE_TEMPLATE/feature_request.yml | Structured form for feature requests with required fields |
| .github/ISSUE_TEMPLATE/config.yml | Disables blank issues and provides documentation contact link |
| .github/ISSUE_TEMPLATE/bug_report.yml | Structured form for bug reports with environment and reproduction steps |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (file.match(/test|spec/)) labels.add('tests'); | ||
| if (file.match(/package\.json|tsconfig|eslint|tailwind/)) labels.add('configuration'); | ||
| if (file.match(/README|\.md$/)) labels.add('documentation'); | ||
| if (file.match(/next\.config|public/)) labels.add('build'); |
There was a problem hiding this comment.
The pattern 'file.match(/next.config|public/)' will match any file with 'public' anywhere in the path, including 'src/utils/publicApi.ts' or 'docs/public-api-spec.md'. Also, 'next.config' without proper anchoring could match 'next.config.backup.txt'. Use more specific patterns like '/(^|/)next.config.(js|mjs|ts)$|(^|/)public//' to match only actual Next.js config files and files within the public directory.
| if (file.match(/next\.config|public/)) labels.add('build'); | |
| if (file.match(/(^|\/)next\.config\.(js|mjs|ts)$|(^|\/)public\//)) labels.add('build'); |
| }) | ||
|
|
||
| - name: Auto-label feature requests | ||
| if: contains(github.event.issue.title, 'feature') || contains(github.event.issue.title, 'enhancement') |
There was a problem hiding this comment.
The feature detection only checks the issue title, not the body, unlike the bug detection which checks both title and body. This inconsistency means feature requests mentioned only in the issue body won't be auto-labeled. Add 'contains(github.event.issue.body, "feature") || contains(github.event.issue.body, "enhancement")' to the condition for consistency.
| if: contains(github.event.issue.title, 'feature') || contains(github.event.issue.title, 'enhancement') | |
| if: contains(github.event.issue.title, 'feature') || contains(github.event.issue.title, 'enhancement') || contains(github.event.issue.body, 'feature') || contains(github.event.issue.body, 'enhancement') |
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@v2 |
There was a problem hiding this comment.
The pnpm action version is outdated. The existing e2e-tests.yml workflow uses pnpm/action-setup@v4, but this new workflow uses pnpm/action-setup@v2. Update to v4 for consistency with the existing workflow and to benefit from the latest improvements.
| uses: pnpm/action-setup@v2 | |
| uses: pnpm/action-setup@v4 |
| branches: [main, develop] | ||
| pull_request: | ||
| branches: [main, develop] |
There was a problem hiding this comment.
The CI workflow runs on 'develop' branch, but the existing e2e-tests.yml workflow runs on 'next-js-migration' branch instead of 'develop'. Verify that 'develop' is a valid branch in the repository, or update to match the actual branching strategy used (which appears to be 'main' and 'next-js-migration' based on the existing e2e-tests.yml workflow).
| branches: [main, develop] | |
| pull_request: | |
| branches: [main, develop] | |
| branches: [main, next-js-migration] | |
| pull_request: | |
| branches: [main, next-js-migration] |
| const labels = new Set(); | ||
|
|
||
| fileNames.forEach(file => { | ||
| if (file.match(/\.(ts|tsx|jsx|js)$/)) labels.add('typescript'); |
There was a problem hiding this comment.
The label 'typescript' is added for any JavaScript or TypeScript file (.ts, .tsx, .jsx, .js), which is misleading. Files with .js or .jsx extensions are JavaScript files, not TypeScript files. Consider renaming this label to 'code', 'javascript', or create separate labels for 'typescript' and 'javascript' based on the actual file extensions.
| if (file.match(/\.(ts|tsx|jsx|js)$/)) labels.add('typescript'); | |
| if (file.match(/\.(ts|tsx)$/)) labels.add('typescript'); | |
| if (file.match(/\.(js|jsx)$/)) labels.add('javascript'); |
| run: pnpm lint 2>/dev/null || echo "Lint script not found, skipping" | ||
| continue-on-error: true | ||
|
|
||
| - name: Type check (if available) | ||
| run: pnpm type-check 2>/dev/null || echo "Type check script not found, skipping" | ||
| continue-on-error: true | ||
|
|
||
| - name: Test (if available) | ||
| run: pnpm test 2>/dev/null || echo "Test script not found, skipping" | ||
| continue-on-error: true | ||
|
|
||
| - name: Build (if available) | ||
| run: pnpm build 2>/dev/null || echo "Build script not found, skipping" | ||
| continue-on-error: true |
There was a problem hiding this comment.
Using 'continue-on-error: true' combined with stderr redirection makes all CI steps succeed regardless of actual failures. This defeats the purpose of CI validation. If a script is not available, the workflow step will always succeed even when the script exists but fails. Consider using a shell script that checks if the script exists in package.json first, then runs it only if available, allowing it to fail properly if it exists but has errors.
| run: pnpm lint 2>/dev/null || echo "Lint script not found, skipping" | |
| continue-on-error: true | |
| - name: Type check (if available) | |
| run: pnpm type-check 2>/dev/null || echo "Type check script not found, skipping" | |
| continue-on-error: true | |
| - name: Test (if available) | |
| run: pnpm test 2>/dev/null || echo "Test script not found, skipping" | |
| continue-on-error: true | |
| - name: Build (if available) | |
| run: pnpm build 2>/dev/null || echo "Build script not found, skipping" | |
| continue-on-error: true | |
| run: pnpm run -s lint --if-present | |
| - name: Type check (if available) | |
| run: pnpm run -s type-check --if-present | |
| - name: Test (if available) | |
| run: pnpm run -s test --if-present | |
| - name: Build (if available) | |
| run: pnpm run -s build --if-present |
| if (file.match(/\.(css|scss|postcss)$/)) labels.add('styling'); | ||
| if (file.match(/test|spec/)) labels.add('tests'); | ||
| if (file.match(/package\.json|tsconfig|eslint|tailwind/)) labels.add('configuration'); |
There was a problem hiding this comment.
The regex pattern for CSS files includes 'postcss' as a file extension, but PostCSS files typically use the .css extension, not .postcss. The pattern should match files like postcss.config.js (configuration) rather than treating .postcss as a style file extension. Consider removing 'postcss' from this pattern or clarifying if .postcss files are actually used in this project.
| if (file.match(/\.(css|scss|postcss)$/)) labels.add('styling'); | |
| if (file.match(/test|spec/)) labels.add('tests'); | |
| if (file.match(/package\.json|tsconfig|eslint|tailwind/)) labels.add('configuration'); | |
| if (file.match(/\.(css|scss)$/)) labels.add('styling'); | |
| if (file.match(/test|spec/)) labels.add('tests'); | |
| if (file.match(/package\.json|tsconfig|eslint|tailwind|postcss\.config/)) labels.add('configuration'); |
| fileNames.forEach(file => { | ||
| if (file.match(/\.(ts|tsx|jsx|js)$/)) labels.add('typescript'); | ||
| if (file.match(/\.(css|scss|postcss)$/)) labels.add('styling'); | ||
| if (file.match(/test|spec/)) labels.add('tests'); |
There was a problem hiding this comment.
The file matching patterns are overly broad. For example, 'file.match(/test|spec/)' will match any file path containing 'test' or 'spec' anywhere in its name or path, including false positives like 'latest.md', 'manifest.json', or 'specification.txt'. Use more specific patterns like '/.(test|spec).(ts|tsx|js|jsx)$/' or check for test directories like '/tests?//' to avoid false positives.
| if (file.match(/test|spec/)) labels.add('tests'); | |
| if (file.match(/(^|\/)__tests__\/|\/tests?\/|\.((test|spec)\.(ts|tsx|js|jsx))$/)) labels.add('tests'); |
| if (file.match(/\.(ts|tsx|jsx|js)$/)) labels.add('typescript'); | ||
| if (file.match(/\.(css|scss|postcss)$/)) labels.add('styling'); | ||
| if (file.match(/test|spec/)) labels.add('tests'); | ||
| if (file.match(/package\.json|tsconfig|eslint|tailwind/)) labels.add('configuration'); |
There was a problem hiding this comment.
The pattern 'file.match(/package.json|tsconfig|eslint|tailwind/)' will match partial filenames. For example, 'my-tailwind-theme.md' or 'tsconfig-notes.txt' would incorrectly get the 'configuration' label. Use more specific patterns like '/^(package.json|.tsconfig..json|.eslint..(js|json)|.tailwind..(js|config))$/' or anchor the patterns to avoid false matches.
| if (file.match(/package\.json|tsconfig|eslint|tailwind/)) labels.add('configuration'); | |
| if ( | |
| file.match(/(^|\/)package\.json$/) || | |
| file.match(/(^|\/).*tsconfig.*\.json$/) || | |
| file.match(/(^|\/).*eslint.*\.(js|cjs|mjs|json|ya?ml)$/) || | |
| file.match(/(^|\/).*tailwind.*\.(js|cjs|mjs|config\.js)$/) | |
| ) labels.add('configuration'); |
| if (file.match(/\.(css|scss|postcss)$/)) labels.add('styling'); | ||
| if (file.match(/test|spec/)) labels.add('tests'); | ||
| if (file.match(/package\.json|tsconfig|eslint|tailwind/)) labels.add('configuration'); | ||
| if (file.match(/README|\.md$/)) labels.add('documentation'); |
There was a problem hiding this comment.
The pattern 'file.match(/README|.md$/)' will match any file containing 'README' anywhere in the path, including code files like 'generateReadme.ts' or 'readmeParser.js'. Use a more specific pattern like '/(^|/)README(.md)?$|.md$/' to match only actual README files and markdown documents.
| if (file.match(/README|\.md$/)) labels.add('documentation'); | |
| if (file.match(/(^|\/)README(\.md)?$|\.md$/)) labels.add('documentation'); |
|
@copilot open a new pull request to apply changes based on the comments in this thread |
|
@danielmarv I've opened a new pull request, #285, to work on those changes. Once the pull request is ready, I'll request review from you. |
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
…gnment Signed-off-by: Daniel Ntege <danientege785@gmail.com>
danielmarv
force-pushed
the
239-newsletter-page-rendering-and-functionality
branch
from
7463cd7 to
bc64d63
Compare
[WIP] Add issue and PR templates and CI workflows
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
…gnment Signed-off-by: Daniel Ntege <danientege785@gmail.com>
Signed-off-by: Daniel Ntege <danientege785@gmail.com>
…ps://github.com/OpenElements/open-elements-website into 239-newsletter-page-rendering-and-functionality
danielmarv
deleted the
239-newsletter-page-rendering-and-functionality
branch
This pull request adds comprehensive GitHub project automation and workflow improvements, including new issue and pull request templates, automated labeling and assignment for issues and PRs, and a continuous integration workflow. These changes are designed to standardize project contributions, streamline triage, and improve developer experience.
Issue and Pull Request Templates:
bug_report.yml) and a feature request template (feature_request.yml) to guide users in providing clear and complete information when reporting issues or suggesting enhancements. [1] [2]pull_request_template.md) to ensure PRs include essential details, testing steps, and a checklist for contributors.config.yml).Automation Workflows:
issue-automation.yml) that auto-labels new issues as bugs or enhancements based on their content and assigns them to a default maintainer.pr-automation.yml) that auto-labels pull requests based on changed files (e.g., typescript, styling, tests, documentation, configuration, build) and assigns the PR to its author.Continuous Integration:
ci.yml) that runs on pushes and pull requests tomainanddevelopbranches, performing dependency installation, linting, type-checking, testing, and building (if scripts are available).