.github file upgrade #22
Conversation
tmikula-dev
requested review from
Zejnilovic,
benedeki and
miroslavpojer
as code owners
WalkthroughComprehensive update to repository Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related issues
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Comment |
tmikula-dev
added
enhancement
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
.github/ISSUE_TEMPLATE/release.md (1)
1-12: Consider adding a release checklist.The template is functional but minimal. Consider adding a checklist section to guide the release process, such as:
- Verify all PRs have release notes
- Run tests
- Tag the release
- Publish release notes
- Update documentation
This would provide more structure and ensure consistent release processes across the team.
.github/ISSUE_TEMPLATE/operative_assignment.md (1)
3-3: Consider shortening the "about" description.The description text is quite verbose: "Issue template for an assignment about setting up the project, it's management or documentation. Usually not touching the codebase."
Consider a more concise version like: "Assignment for project setup, management, or documentation"
Also note the grammatical error: "it's management" should be "its management" (possessive, not contraction).
.github/ISSUE_TEMPLATE/spike.md (1)
28-32: Consider clarifying the placeholder task item.Line 32 includes a placeholder task
- [ ] item here...which may confuse users. If intended as a helper example, consider replacing it with a more descriptive comment or guidance, or remove it entirely if the previous tasks are sufficiently comprehensive.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
.github/CODEOWNERS(1 hunks).github/ISSUE_TEMPLATE/bug_report.md(2 hunks).github/ISSUE_TEMPLATE/epic.md(1 hunks).github/ISSUE_TEMPLATE/feature_request.md(1 hunks).github/ISSUE_TEMPLATE/operative_assignment.md(1 hunks).github/ISSUE_TEMPLATE/operative_task.md(0 hunks).github/ISSUE_TEMPLATE/release.md(1 hunks).github/ISSUE_TEMPLATE/spike.md(2 hunks).github/ISSUE_TEMPLATE/technical_debt.md(1 hunks).github/pull_request_template.md(1 hunks).github/workflows/check_pr_release_notes.yml(2 hunks).github/workflows/release_draft.yml(2 hunks)
💤 Files with no reviewable changes (1)
- .github/ISSUE_TEMPLATE/operative_task.md
🧰 Additional context used
🪛 LanguageTool
.github/ISSUE_TEMPLATE/bug_report.md
[style] ~25-~25: Consider using a different verb for a more formal wording.
Context: ...team to confirm that the issue has been fixed. ## Screenshots If applicable, add scr...
(FIX_RESOLVE)
🔇 Additional comments (17)
.github/ISSUE_TEMPLATE/bug_report.md (3)
3-3: Minor wording improvement.The updated wording "Create a report for a bug found or identified" is clearer than the typical "Create a bug report" phrasing.
8-9: Good addition: Template versioning.Adding the template version marker enables tracking template evolution across repositories, which aligns well with the PR objective of unifying standards across QA projects.
23-26: Valuable addition: Business Value section.The Business Value section helps prioritize bug fixes and track impact. The wording is clear and actionable.
Note: The static analysis tool suggested changing "fixed" to a different verb for formality, but "fixed" is standard terminology in bug tracking and perfectly appropriate here.
.github/ISSUE_TEMPLATE/epic.md (1)
8-18: LGTM: Consistent standardization.The additions (template version marker and Business Value section) are consistent with the pattern applied across all issue templates in this PR, supporting the unified standard objective.
.github/ISSUE_TEMPLATE/technical_debt.md (1)
8-25: Well-structured template.The template provides comprehensive guidance for documenting technical debt with clear sections for risk assessment, conditions, impact, and solutions. This will help teams properly evaluate and prioritize technical debt.
.github/ISSUE_TEMPLATE/feature_request.md (1)
3-3: LGTM: Template improvements applied consistently.The changes improve the template:
- Wording refinement (line 3)
- Template versioning (lines 8-9)
- Business Value section (lines 16-18)
- Corrected list formatting (lines 24-26)
All align with the standardization effort across templates.
Also applies to: 8-9, 16-18, 24-26
.github/pull_request_template.md (1)
1-11: Excellent PR template structure.The template provides clear guidance with:
- Overview section for context
- Release Notes section with TBD placeholders (encourages documentation)
- Related section with proper GitHub issue linking syntax
This structure will improve PR quality and documentation consistency across the project.
.github/ISSUE_TEMPLATE/operative_assignment.md (1)
1-12: Good template for operational work.The template appropriately distinguishes operational assignments from code changes with the "no RN" label and provides clear structure for tracking infrastructure and documentation work.
.github/CODEOWNERS (1)
1-1: Verify the reduction in code owners and self-addition.The changes are confirmed:
- Previous:
@miroslavpojer @Zejnilovic @benedeki- Current:
@miroslavpojer @tmikula-devThe removal of @Zejnilovic and @benedeki alongside adding @tmikula-dev (the PR author) as part of a ".github file upgrade" commit requires validation. The repository's CONTRIBUTING.md does not document governance policies or approval requirements for code owner changes.
Confirm:
- Is this change authorized by the team or project leadership?
- Has the removal of existing owners been formally approved?
- Does adding the PR author as a code owner align with your project's governance practices?
.github/ISSUE_TEMPLATE/spike.md (2)
8-22: Template standardization is well-structured.The version marker and new Business Value section align well with the PR objective to standardize .github files across projects. The phrasing is clear and provides necessary guidance.
34-38: List formatting correction is solid.The switch from malformed list syntax to proper markdown numbering improves template clarity and consistency with other updated templates in this PR.
.github/workflows/check_pr_release_notes.yml (2)
29-31: Verify Python 3.13 compatibility and support.The update to actions/setup-python@v6 and Python 3.13 aligns with the standardization effort. Ensure that Python 3.13 is stable for your project's needs and that all dependent tools (release-notes-presence-check and any custom scripts) support this version.
34-42: I cannot locate the AbsaOSS/release-notes-presence-check repository or its v0.4.0 documentation through web searches. The search results do not return the specific GitHub repository or changelog needed to verify whetherskip-placeholdersparameter is officially supported in v0.4.0.
Without access to official documentation for AbsaOSS/release-notes-presence-check@v0.4.0, I cannot definitively verify that the
skip-placeholdersparameter is documented as supported. The upgrade and new parameters appear reasonable, but confirmation requires checking the action's official README, action.yml, or v0.4.0 release notes directly. Please verify this action version and parameter support in the official repository before merging..github/workflows/release_draft.yml (4)
17-26: Workflow redesign adds flexibility for release notes generation.The new optional
from-tag-nameinput enables users to generate release notes comparing against a specific previous tag, providing better control over changelog scope. Documentation and syntax validation are clear.
32-59: Action versions and validation logic are well-structured.The two-phase validation (mandatory tag-name + optional from-tag-name with existence check) provides proper safeguards. The conditional prevents unnecessary execution when from-tag-name is not provided. All action versions align with the standardization effort.
90-117: I need to gather more information about softprops/action-gh-release v2 parameters and the generate-release-notes action output. Let me search for this information.No issues found. Action versions are compatible.
Softprops/action-gh-release@v2 supports the parameters used: name (defaults to tag name), tag_name (defaults to github.ref_name), and draft. The prerelease parameter is also supported in v2. The body parameter is confirmed in v2 documentation.
The github-script@v8 upgrade only requires Node.js version support and minimum runner version v2.327.1, which does not affect the script syntax used in your workflow. Your inline script with
core.getInput()andgithub.rest.git.createRef()is compatible.
61-88: The search results confirm most parameters are supported features in v1, but the summary is incomplete. Let me search for the exact action input schema:Verify AbsaOSS/generate-release-notes action version and parameter names.
The official repository example (master branch) uses
skip-release-notes-label(singular) and simpler parameters, but your workflow usesskip-release-notes-labels(plural) along withduplicity-scope,row-format-*, andhierarchy—which do not appear in accessible documentation or examples.Additionally, no v1 release could be located; the latest example references v0.6.0. Confirm:
- The action version reference (@v1) is correct
- All parameters used (especially
skip-release-notes-labels,duplicity-scope,row-format-issue,row-format-pr,row-format-link-pr,hierarchy,print-empty-chapters) are valid for your target version
| --- | ||
| name: Technical debt | ||
| about: Technical debt identified or created in the project | ||
| labels: 'tech debt' | ||
| type: 'Feature' | ||
| --- |
There was a problem hiding this comment.
Fix the issue type classification.
Technical debt is classified as type: 'Feature', which is semantically incorrect. Technical debt represents maintenance work, not new features.
Consider changing to:
-type: 'Feature'
+type: 'Task'Alternatively, if your issue tracking system supports it, use type: 'Technical Debt' for better categorization.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| --- | |
| name: Technical debt | |
| about: Technical debt identified or created in the project | |
| labels: 'tech debt' | |
| type: 'Feature' | |
| --- | |
| --- | |
| name: Technical debt | |
| about: Technical debt identified or created in the project | |
| labels: 'tech debt' | |
| type: 'Task' | |
| --- |
🤖 Prompt for AI Agents
In .github/ISSUE_TEMPLATE/technical_debt.md around lines 1 to 6, the frontmatter
sets type: 'Feature' which misclassifies technical debt; update the YAML
frontmatter to use a more accurate type such as type: 'Technical Debt' or type:
'Maintenance' (or remove the type field if your tracker does not support custom
types) so that issues are correctly categorized as maintenance work rather than
features.
| - name: Check Format of Received From Tag | ||
| if: ${{ github.event.inputs.from-tag-name }} | ||
| id: check-version-from-tag | ||
| uses: AbsaOSS/version-tag-check@v0.3.0 | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| with: | ||
| python-version: '3.11' | ||
| github-repository: ${{ github.repository }} | ||
| version-tag: ${{ github.event.inputs.from-tag-name }} | ||
| should-exist: true | ||
|
|
||
| - name: Generate Release Notes | ||
| id: generate_release_notes | ||
| uses: AbsaOSS/generate-release-notes@v0.4.0 | ||
| uses: AbsaOSS/generate-release-notes@v1 | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| with: | ||
| tag-name: ${{ github.event.inputs.tag-name }} | ||
| chapters: '[ | ||
| {"title": "No entry 🚫", "label": "duplicate"}, | ||
| {"title": "No entry 🚫", "label": "invalid"}, | ||
| {"title": "No entry 🚫", "label": "wontfix"}, | ||
| {"title": "No entry 🚫", "label": "no RN"}, | ||
| {"title": "Breaking Changes 💥", "label": "breaking-change"}, | ||
| {"title": "New Features 🎉", "label": "enhancement"}, | ||
| {"title": "New Features 🎉", "label": "feature"}, | ||
| {"title": "Bugfixes 🛠", "label": "bug"}, | ||
| {"title": "Infrastructure ⚙️", "label": "infrastructure"}, | ||
| {"title": "Silent-live 🤫", "label": "silent-live"}, | ||
| {"title": "Documentation 📜", "label": "documentation"} | ||
| ]' | ||
| skip-release-notes-label: 'no RN' | ||
| verbose: true | ||
|
|
||
| chapters: | | ||
| - {"title": "Entries to skip 🚫", "label": "duplicate"} | ||
| - {"title": "Entries to skip 🚫", "label": "invalid"} | ||
| - {"title": "Entries to skip 🚫", "label": "wontfix"} | ||
| - {"title": "Entries to skip 🚫", "label": "no RN"} | ||
| - {"title": "Breaking Changes 💥", "label": "breaking change"} | ||
| - {"title": "Security updates 👮", "label": "security"} | ||
| - {"title": "New Features 🎉", "label": "enhancement"} | ||
| - {"title": "Bugfixes 🛠", "label": "bug"} | ||
| - {"title": "Epics 📖", "label": "epic"} | ||
| - {"title": "Infrastructure ⚙️", "label": "infrastructure"} | ||
| - {"title": "Silent-live 🤫", "label": "silent live"} | ||
| - {"title": "Documentation 📜", "label": "documentation"} | ||
| duplicity-scope: 'none' | ||
| warnings: true | ||
| print-empty-chapters: true | ||
|
|
||
| skip-release-notes-labels: "no RN,duplicate,invalid,wontfix" | ||
| print-empty-chapters: false | ||
| row-format-issue: '_{title}_ {developers} in {number}' | ||
| row-format-pr: '_{title}_ {developers} in {number}' | ||
| row-format-link-pr: true | ||
| hierarchy: true |
There was a problem hiding this comment.
🧩 Analysis chain
Critical: Optional from-tag-name input is validated but not used.
The workflow validates the optional from-tag-name input (lines 50-59) but does not pass it to the "Generate Release Notes" step. This creates a disconnect: users can provide a from-tag-name, which passes validation, but the release notes generation may not use it.
The Generate Release Notes action (line 63) should receive the from-tag-name parameter:
- name: Generate Release Notes
id: generate_release_notes
uses: AbsaOSS/generate-release-notes@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag-name: ${{ github.event.inputs.tag-name }}
+ from-tag-name: ${{ github.event.inputs.from-tag-name }}
chapters: |Alternatively, if the action doesn't support from-tag-name, clarify the intended behavior in documentation or remove the input entirely.
🌐 Web query:
AbsaOSS/generate-release-notes@v1 action parameters from-tag-name
💡 Result:
The action supports an optional from-tag-name input to set the lower bound of the tag range so the notes cover from from-tag-name...tag-name (i.e., compare from-tag-name..tag-name). Use it together with tag-name; if omitted the action uses the repository's latest state/previous release as the start. Example (in your workflow step):
- name: Generate Release Notes
uses: AbsaOSS/generate-release-notes@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag-name: "v1.2.0"
from-tag-name: "v1.1.0"
chapters: |
- {"title":"New Features 🎉","labels":"enhancement"}
(Documentation reference: README — Tag Range Selection uses tag-name/from-tag-name.) [1]
Sources
- AbsaOSS/generate-release-notes README (Tag Range Selection / configuration). [1]
🌐 Web query:
AbsaOSS generate-release-notes action supported inputs documentation
💡 Result:
The AbsaOSS generate-release-notes Action README documents these supported inputs (use via with: or env:):
- GITHUB_TOKEN (env) — GitHub token for API access. [required].
- tag-name — Target tag for the release (string). [required].
- chapters — YAML multiline mapping of chapter titles → labels (supports
labelorlabels). [optional]. - verbose — enable detailed logging (boolean, default: false). [optional].
The README also shows the action outputs (e.g., release_notes) and additional features/config options (from-tag-name/date selection, skip/duplicity settings, custom row formats, service chapters, etc.) exposed elsewhere in the docs. See the full docs and examples in the repository README. [1]
Sources
[1] AbsaOSS/generate-release-notes README (inputs, configuration, examples).
Critical: Optional from-tag-name input is validated but not passed to the release notes action.
The workflow validates from-tag-name at lines 50–59 but does not pass it to the "Generate Release Notes" step. The action supports an optional from-tag-name input to set the lower bound of the tag range so the notes cover from from-tag-name...tag-name, allowing users to specify a comparison range. Without this parameter, the action ignores the user-provided value.
Pass from-tag-name to the action:
- name: Generate Release Notes
id: generate_release_notes
uses: AbsaOSS/generate-release-notes@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag-name: ${{ github.event.inputs.tag-name }}
+ from-tag-name: ${{ github.event.inputs.from-tag-name }}
chapters: |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Check Format of Received From Tag | |
| if: ${{ github.event.inputs.from-tag-name }} | |
| id: check-version-from-tag | |
| uses: AbsaOSS/version-tag-check@v0.3.0 | |
| env: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | |
| with: | |
| python-version: '3.11' | |
| github-repository: ${{ github.repository }} | |
| version-tag: ${{ github.event.inputs.from-tag-name }} | |
| should-exist: true | |
| - name: Generate Release Notes | |
| id: generate_release_notes | |
| uses: AbsaOSS/generate-release-notes@v0.4.0 | |
| uses: AbsaOSS/generate-release-notes@v1 | |
| env: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | |
| with: | |
| tag-name: ${{ github.event.inputs.tag-name }} | |
| chapters: '[ | |
| {"title": "No entry 🚫", "label": "duplicate"}, | |
| {"title": "No entry 🚫", "label": "invalid"}, | |
| {"title": "No entry 🚫", "label": "wontfix"}, | |
| {"title": "No entry 🚫", "label": "no RN"}, | |
| {"title": "Breaking Changes 💥", "label": "breaking-change"}, | |
| {"title": "New Features 🎉", "label": "enhancement"}, | |
| {"title": "New Features 🎉", "label": "feature"}, | |
| {"title": "Bugfixes 🛠", "label": "bug"}, | |
| {"title": "Infrastructure ⚙️", "label": "infrastructure"}, | |
| {"title": "Silent-live 🤫", "label": "silent-live"}, | |
| {"title": "Documentation 📜", "label": "documentation"} | |
| ]' | |
| skip-release-notes-label: 'no RN' | |
| verbose: true | |
| chapters: | | |
| - {"title": "Entries to skip 🚫", "label": "duplicate"} | |
| - {"title": "Entries to skip 🚫", "label": "invalid"} | |
| - {"title": "Entries to skip 🚫", "label": "wontfix"} | |
| - {"title": "Entries to skip 🚫", "label": "no RN"} | |
| - {"title": "Breaking Changes 💥", "label": "breaking change"} | |
| - {"title": "Security updates 👮", "label": "security"} | |
| - {"title": "New Features 🎉", "label": "enhancement"} | |
| - {"title": "Bugfixes 🛠", "label": "bug"} | |
| - {"title": "Epics 📖", "label": "epic"} | |
| - {"title": "Infrastructure ⚙️", "label": "infrastructure"} | |
| - {"title": "Silent-live 🤫", "label": "silent live"} | |
| - {"title": "Documentation 📜", "label": "documentation"} | |
| duplicity-scope: 'none' | |
| warnings: true | |
| print-empty-chapters: true | |
| skip-release-notes-labels: "no RN,duplicate,invalid,wontfix" | |
| print-empty-chapters: false | |
| row-format-issue: '_{title}_ {developers} in {number}' | |
| row-format-pr: '_{title}_ {developers} in {number}' | |
| row-format-link-pr: true | |
| hierarchy: true | |
| - name: Check Format of Received From Tag | |
| if: ${{ github.event.inputs.from-tag-name }} | |
| id: check-version-from-tag | |
| uses: AbsaOSS/version-tag-check@v0.3.0 | |
| env: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | |
| with: | |
| github-repository: ${{ github.repository }} | |
| version-tag: ${{ github.event.inputs.from-tag-name }} | |
| should-exist: true | |
| - name: Generate Release Notes | |
| id: generate_release_notes | |
| uses: AbsaOSS/generate-release-notes@v1 | |
| env: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | |
| with: | |
| tag-name: ${{ github.event.inputs.tag-name }} | |
| from-tag-name: ${{ github.event.inputs.from-tag-name }} | |
| chapters: | | |
| - {"title": "Entries to skip 🚫", "label": "duplicate"} | |
| - {"title": "Entries to skip 🚫", "label": "invalid"} | |
| - {"title": "Entries to skip 🚫", "label": "wontfix"} | |
| - {"title": "Entries to skip 🚫", "label": "no RN"} | |
| - {"title": "Breaking Changes 💥", "label": "breaking change"} | |
| - {"title": "Security updates 👮", "label": "security"} | |
| - {"title": "New Features 🎉", "label": "enhancement"} | |
| - {"title": "Bugfixes 🛠", "label": "bug"} | |
| - {"title": "Epics 📖", "label": "epic"} | |
| - {"title": "Infrastructure ⚙️", "label": "infrastructure"} | |
| - {"title": "Silent-live 🤫", "label": "silent live"} | |
| - {"title": "Documentation 📜", "label": "documentation"} | |
| duplicity-scope: 'none' | |
| warnings: true | |
| skip-release-notes-labels: "no RN,duplicate,invalid,wontfix" | |
| print-empty-chapters: false | |
| row-format-issue: '_{title}_ {developers} in {number}' | |
| row-format-pr: '_{title}_ {developers} in {number}' | |
| row-format-link-pr: true | |
| hierarchy: true |
🤖 Prompt for AI Agents
.github/workflows/release_draft.yml around lines 50 to 88: the workflow
validates github.event.inputs.from-tag-name but does not forward it to the
"Generate Release Notes" action, so the action cannot use the lower bound for
the tag range; fix by adding a with input named from-tag-name and set it to ${{
github.event.inputs.from-tag-name }} (the action accepts this optional input),
ensuring the value is passed through so release notes cover
from-tag-name...tag-name.
Overview
.github file upgrade to unite it across the QA projects.
Release Notes
Related
Closes #21
Summary by CodeRabbit
Release Notes