.github file upgrade #100
.github file upgrade #100
Conversation
tmikula-dev
requested review from
lsulak,
oto-macenauer-absa and
petr-pokorny-absa
as code owners
WalkthroughThis PR upgrades repository GitHub configuration by migrating issue templates from Markdown to YAML format, introducing five new template types (DevOps, documentation, operative, pointer, technical debt), adding a standardized pull request template, and updating CI/CD workflows with pinned action versions and enhanced release notes configuration. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas requiring extra attention:
Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Trivy has completed a full security repository scan ✅ You can find the analysis results for this PR branch on this overview.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release_draft.yml (1)
17-120: Add explicit workflowpermissionsand make tag creation idempotent (re-run safe).
- Missing explicit
permissions: contents: write: The GITHUB_TOKEN defaults to read-only (contents: read) on new repositories and organizations (since Feb 2, 2023). Tag creation and draft release require explicit write permission. Without it, the workflow will fail at runtime when attempting to create the tag or release.- The "Create and Push Tag" step (lines 91–109) will hard-fail if the tag already exists, which occurs on re-run or after partial failure. Check for the existing ref first and skip creation if it already exists to make the workflow safely re-runnable.
Example patch:
name: Draft Release +permissions: + contents: write on: workflow_dispatch: @@ - name: Create and Push Tag uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd @@ script: | const tag = process.env.TAG_NAME const ref = `refs/tags/${tag}`; const sha = context.sha; // The SHA of the commit to tag + + // Make re-runs safer: skip if tag already exists + try { + await github.rest.git.getRef({ + owner: context.repo.owner, + repo: context.repo.repo, + ref: `tags/${tag}`, + }); + core.info(`Tag already exists, skipping createRef: ${tag}`); + return; + } catch (e) { + // 404 means not found => create it; otherwise rethrow + if (e.status !== 404) throw e; + } await github.rest.git.createRef({ owner: context.repo.owner, repo: context.repo.repo, ref: ref, sha: sha });
🧹 Nitpick comments (4)
.github/pull_request_template.md (1)
10-11: Make the issue placeholder more actionable.The generic
#issue_numberplaceholder could be confusing for contributors. Provide an example or guidance to clarify the format and explain linking conventions.Consider updating to:
-Closes #issue_number +Closes #<issue_number> <!-- Link the resolved issue here -->Alternatively, if you prefer even more guidance:
+<!-- Link related issues/PRs: Closes #123, Related #456 --> +Closes #issue_number.github/ISSUE_TEMPLATE/devops_task.yml (1)
1-17: Consider adding structured fields for DevOps task details.While the minimal template is straightforward, DevOps tasks often benefit from additional structure (environment, rollback plan, impact, validation). Consider expanding slightly to capture these aspects without overwhelming the form.
Example additions:
- type: input id: environment attributes: label: Target Environment placeholder: dev, staging, production validations: required: true - type: textarea id: rollback-plan attributes: label: Rollback Plan description: Steps to revert if needed validations: required: falseThis is optional; keep it minimal if your team prefers lightweight task capture.
.github/ISSUE_TEMPLATE/technical_debt.yml (1)
1-96: Align/verify thetech debtlabel name (and existence) to avoid silent non-application.
- Line 3: If
tech debtisn’t an existing label, it won’t get applied. Also consider standardizing naming across repos (e.g.,tech-debtvstech debt) to keep automation consistent..github/ISSUE_TEMPLATE/bug_report.yml (1)
1-82: Bug template is solid; tweak “Environment” wording and add a redaction reminder for logs.
- Line 66-71: Consider renaming the field label from “Desktop” to “Environment” to cover server/CLI/mobile cases.
- Line 57-60: Consider adding “(please redact secrets/PII)” to the evidence description to reduce accidental leakage.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
.github/ISSUE_TEMPLATE/bug_report.md(0 hunks).github/ISSUE_TEMPLATE/bug_report.yml(1 hunks).github/ISSUE_TEMPLATE/devops_task.yml(1 hunks).github/ISSUE_TEMPLATE/documentation_task.yml(1 hunks).github/ISSUE_TEMPLATE/epic_task.md(0 hunks).github/ISSUE_TEMPLATE/epic_task.yml(1 hunks).github/ISSUE_TEMPLATE/feature_request.md(0 hunks).github/ISSUE_TEMPLATE/feature_request.yml(1 hunks).github/ISSUE_TEMPLATE/operative_task.yml(1 hunks).github/ISSUE_TEMPLATE/pointer.yml(1 hunks).github/ISSUE_TEMPLATE/question.md(0 hunks).github/ISSUE_TEMPLATE/spike_task.md(0 hunks).github/ISSUE_TEMPLATE/spike_task.yml(1 hunks).github/ISSUE_TEMPLATE/technical_debt.yml(1 hunks).github/pull_request_template.md(1 hunks).github/workflows/check_pr_release_notes.yml(2 hunks).github/workflows/release_draft.yml(4 hunks)
💤 Files with no reviewable changes (5)
- .github/ISSUE_TEMPLATE/question.md
- .github/ISSUE_TEMPLATE/epic_task.md
- .github/ISSUE_TEMPLATE/feature_request.md
- .github/ISSUE_TEMPLATE/spike_task.md
- .github/ISSUE_TEMPLATE/bug_report.md
🔇 Additional comments (7)
.github/ISSUE_TEMPLATE/documentation_task.yml (1)
1-53: Well-designed documentation template.The template structure is clear, with a logical field progression and helpful context. Required/optional field balance is appropriate; descriptions and placeholders guide contributors effectively.
.github/workflows/check_pr_release_notes.yml (2)
40-42: Good release notes validation strategy.The combination of title pattern matching, skip-labels, and skip-placeholders provides flexibility. The use of
TBDplaceholders aligns well with the new PR template, allowing contributors to draft notes during development without blocking CI.
29-29: SHA pinning is properly implemented with current, valid action versions.Both pinned SHAs reference legitimate published releases:
actions/setup-python@83679a892e2d95755f2dac6acb0bfd1e9ac5d548→ v6.1.0 (current stable version)AbsaOSS/release-notes-presence-check@8e586b26a5e27f899ee8590a5d988fd4780a3dbf→ v0.4.0 (latest stable version)No action required.
.github/ISSUE_TEMPLATE/pointer.yml (1)
1-71: Excellent pointer template design.The structured fields effectively capture cross-repository dependencies. The dropdown for relationship type is particularly well-designed, and the closure conditions field encourages clear resolution criteria. This template addresses a valuable use case for tracking external work.
.github/ISSUE_TEMPLATE/feature_request.yml (1)
1-65: Well-structured feature request template.The progression from description → problem → acceptance criteria is thoughtful and guides contributors to think through requirements. The acceptance criteria section is especially valuable for clarity during implementation.
.github/ISSUE_TEMPLATE/epic_task.yml (1)
1-47: Solid epic task template.The required Background and Goals fields establish clear strategic intent. The optional Subtasks and References fields provide useful structure without over-constraining large initiatives. The checkbox placeholder is helpful guidance.
.github/ISSUE_TEMPLATE/spike_task.yml (1)
1-60: Well-designed spike template with good task discipline.The required fields (Background, Questions, Desired Outcome) establish clear scope. The checkboxes for common spike deliverables (team discussion, documentation, follow-up tickets) are excellent UX and help prevent incomplete spikes. The "keep scope tight" guidance is appropriate.
| name: Operative / Management Task | ||
| description: General-purpose template for operational, management, and non-development tasks | ||
| labels: ["operative"] | ||
| body: | ||
| - type: markdown | ||
| attributes: | ||
| value: | | ||
| Use this flexible template for operational, management, planning, or administrative tasks. | ||
|
|
||
| - type: input | ||
| id: summary | ||
| attributes: | ||
| label: Task Summary | ||
| description: Brief one-line description of the task | ||
| placeholder: e.g., Organize Q2 planning meeting, Update team guidelines. | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: textarea | ||
| id: description | ||
| attributes: | ||
| label: Description | ||
| description: Detailed description of what needs to be done and why | ||
| placeholder: Provide context, background, and objectives for this task | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: textarea | ||
| id: objectives | ||
| attributes: | ||
| label: Objectives / Goals | ||
| description: What are we trying to achieve? | ||
| placeholder: | | ||
| - Objective 1 | ||
| - Objective 2 | ||
| validations: | ||
| required: false | ||
|
|
||
| - type: input | ||
| id: deadline | ||
| attributes: | ||
| label: Deadline / Target Date | ||
| description: When should this be completed? | ||
| placeholder: YYYY-MM-DD or "End of Sprint 5" | ||
| validations: | ||
| required: false | ||
|
|
||
| - type: textarea | ||
| id: additional-context | ||
| attributes: | ||
| label: Additional Context | ||
| description: Any other relevant information, links, or attachments | ||
| placeholder: Links to documents, previous discussions, related materials | ||
| validations: | ||
| required: false |
There was a problem hiding this comment.
Ensure the operative label exists; consider tightening “Deadline / Target Date” guidance.
- Line 3: If the
operativelabel doesn’t exist in the repo, it won’t be applied (and users won’t notice). Consider adding/standardizing it (or choosing an existing label). - Line 39-46: Since issue forms can’t enforce date formats, consider clarifying the placeholder/help text to prefer ISO
YYYY-MM-DDonly (or rename to “Target timeframe” if you want flexibility).
🤖 Prompt for AI Agents
.github/ISSUE_TEMPLATE/operative_task.yml lines 1-55: the template references a
non-guaranteed "operative" label and provides ambiguous deadline guidance;
update the repository or template so the label is reliable (either create/add
the "operative" label to the repo or replace it with an existing standardized
label and document its use), and tighten the deadline field guidance by changing
the placeholder/description to prefer ISO format "YYYY-MM-DD" only (or
alternatively rename the field to "Target timeframe" if flexibility is intended)
so users get clear instructions.
Overview
.github file upgrade to unite it across the CA projects.
Release Notes
Related
Closes #99
Summary by CodeRabbit
Release Notes
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.