Enforce PR Title Convention & Description Requirements in CI/CD Pipeline

[phertyameen]

Enforce PR Quality Standards via CI and Contributing Guidelines

Problem

Contributors are submitting pull requests with little to no context titles like "update" or descriptions that only say "Closes #22". This makes it difficult for maintainers to understand what a PR does at a glance, slows down reviews, and pollutes the project's commit history.

Expected Outcome

• The CI pipeline should automatically reject PRs that do not meet a minimum quality bar, so maintainers are not the ones policing this manually.
• PR titles should follow a consistent convention that produces a readable commit history.
• PR descriptions should contain enough context for a maintainer to understand the change without having to read every line of code.
• CONTRIBUTING.md should be updated to clearly communicate these expectations to contributors before they even open a PR, including the branching convention (feature/your-feature-name) required for PR submission.

What to Do

PRs with minimal descriptions like "Closes #22" make it hard for maintainers to understand changes at a glance. This issue proposes two changes:

1. Workflow Changes — Add PR Validation Job

Add a new job validate-pr to .github/workflows/ci-cd.yml before the existing build-and-deploy job. Do not touch any commented-out lines in the file.

Also update the build-and-deploy job to depend on validate-pr so a failing validation blocks the build:

  build-and-deploy:
    needs: validate-pr   # ← add this line
    runs-on: ubuntu-latest

2. Update CONTRIBUTING.md

Add (or update) the following sections in CONTRIBUTING.md:

---

Branch Naming Convention

All feature branches must follow this naming pattern before opening a PR:

feature/your-feature-name
fix/short-description
docs/what-you-documented

Examples:

• feature/user-authentication
• fix/null-pointer-login
• docs/update-api-reference

PRs submitted from branches that do not follow this convention may be closed without review.

---

Pull Request Title

PR titles must follow the Conventional Commits format:

<type>: <short description (min 10 characters)>

Allowed types: feat, fix, docs, style, refactor, perf, test, chore, ci, build, revert

Examples:

• ✅ feat: add OAuth2 login support
• ✅ fix: resolve crash on empty cart checkout
• ✅ docs: update installation steps for Windows
• ❌ Closes #22
• ❌ fix: x
• ❌ updates

The CI pipeline will automatically reject PRs that do not meet this format.

Pull Request Description

Every PR must include a meaningful description. A bare issue reference like Closes #22 is not acceptable as a full description.

Your PR body should answer:

• What problem does this PR solve?
• How did you solve it?
• Any relevant context, screenshots, or testing notes?

PRs with fewer than 15 words in the description will be rejected by CI.

Acceptance Criteria

• CI fails on any PR with a non-conforming title
• CI fails on any PR with an empty or insufficiently descriptive body
• CONTRIBUTING.md reflects the new requirements around PR titles, descriptions, and branch naming
• Existing workflow behaviour (build, lint, test) is not affected

Notes

• The existing .github/workflows/ci-cd.yml should be modified, not replaced
• Do not alter any commented-out sections in the workflow file

[drips-wave]

This issue has been added to the Stellar Wave Program and is worth 100 Points.

🧑‍💻 Interested in contributing? Apply to work on this issue on Drips Wave, earn points, and receive rewards.

Warning

Only applications submitted via the apply link above will be considered. Please do not apply by commenting on the issue or opening a PR directly.

🤠 Repo maintainers: You can manage this issue's Points and Complexity on your Maintainer Dashboard here. Please keep an eye on applications and respond quickly 💙

ℹ️ Learn more about Drips Wave

[Xoulomon]

@Xoulomon has applied to work on this issue as part of the Stellar Wave Program's 2nd wave.

Hi @phertyameen,

I'm interested in enforcing these PR quality standards via the CI/CD pipeline. I can implement the validate-pr job in your existing .github/workflows/ci-cd.yml to programmatically check for Conventional Commit titles and minimum description lengths, while updating the CONTRIBUTING.md to ensure these new standards are clearly documented for the community.

My background/relevant experience:

CI/CD Governance: I have experience building GitHub Actions that use regex and custom scripts to enforce Conventional Commits and metadata requirements (like minimum word counts) on Pull Requests.

Workflow Orchestration: Proficient in managing job dependencies (using needs:) to ensure quality gates block downstream processes like build-and-deploy without disrupting existing logic.

Project Documentation: I’ve successfully maintained and updated CONTRIBUTING.md files for open-source projects to align developer expectations with automated enforcement.

Clean History Advocate: I understand the value of strict branching conventions (feature/, fix/) and how they contribute to a readable and maintainable project history.

If this fits, could you assign the issue to me? I'm ready to harden your PR process while strictly respecting the existing commented-out code in your workflow.

Thanks!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Xoulomon to this issue.

[drips-wave]

Congratulations, @Xoulomon! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on February 26, 2026.

🧑‍💻 @Xoulomon: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are issued when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊