ch(action): added github workflows #4
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds GitHub workflow automation to validate development practices including commit message format, branch naming conventions, and pull request descriptions.
- Implements three validation workflows for commit messages, branch names, and PR descriptions
- Enforces conventional commit format with specific types (feat, fix, chore, etc.)
- Validates branch naming pattern following Azure DevOps task integration format
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/validate-commits.yml | Validates commit messages follow conventional format on push events |
| .github/workflows/validate-branch-name.yml | Enforces branch naming convention for pull requests |
| .github/workflows/pr-body-validator.yml | Ensures PR descriptions contain required sections and content |
| echo "Validating: '${{ steps.get_commit.outputs.commit_msg }}'" | ||
| if [[ ! "${{ steps.get_commit.outputs.commit_msg }}" =~ ^(feat|fix|chore|docs|style|refactor|test|perf|ci|build|revert)(\(.+\))?:\ .+ ]]; then | ||
| echo "❌ Invalid commit message format." | ||
| echo "💡 Expected format: 'type(scope): description', e.g., 'feat(auth): add login API'" |
There was a problem hiding this comment.
The regex pattern has an inconsistency with the error message. The pattern includes 'chore' but the error message example shows 'type(scope): description' format. The commit message in the PR title uses 'ch(action):' which doesn't match either 'chore' or the documented types.
| echo "💡 Expected format: 'type(scope): description', e.g., 'feat(auth): add login API'" | |
| echo "💡 Expected format: 'type(scope): description', where type is one of feat, fix, chore, docs, style, refactor, test, perf, ci, build, revert. Example: 'feat(auth): add login API' or 'chore(deps): update dependencies'" |
|
|
||
| # Allowed types: ft, bg, ch, rf | ||
| # Format: {type}-{summary}-{id} | ||
| BRANCH_REGEX='^(ft|bg|ch|rf)-[a-z0-9]+(-[a-z0-9]+){1,2}-[0-9]+$' |
There was a problem hiding this comment.
The regex pattern allows only 1-2 additional dash-separated segments, but the documentation on line 30 states '2–3 lowercase words' for the summary. This creates confusion about whether the summary can have 2 or 3 words.
| content="${field_content[$field]}" | ||
| if [ -z "$content" ]; then | ||
| errors+=("❌ Missing content for: $field") | ||
| elif echo "$content" | grep -iq "^N/A$"; then |
There was a problem hiding this comment.
The grep pattern uses ^N/A$ which only matches exactly 'N/A' as the entire content, but the content variable may contain multiple lines or additional whitespace. This could miss variations like 'n/a', 'N/a', or 'N/A' with surrounding text.
| elif echo "$content" | grep -iq "^N/A$"; then | |
| elif echo "$content" | grep -iq '^\s*n/a\s*$'; then |
Description of Task?
weqeqwe
Any background context you want to provide?
eqwewqeqw
What are the relevant user stories or tasks links from Azure DevOps?
ewqeqwewqeqweqweqweqweqw
Screenshots (if appropriate)