Skip to content

Commit 9e5a5df

Browse files
Tiberriver256Tiberriver256
committed
feat: implement automated release workflow
1 parent bbd4e82 commit 9e5a5df

File tree

6 files changed

+4527
-293
lines changed

6 files changed

+4527
-293
lines changed

‎.clinerules

+6
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,12 @@
22

33
⚠️ CRITICAL: DO NOT USE attempt_completion BEFORE TESTING ⚠️
44

5+
## Commit Rules
6+
7+
⚠️ MANDATORY: All git commits MUST adhere to the Conventional Commits specification (https://www.conventionalcommits.org/). Example: 'feat: implement user login' or 'fix: resolve calculation error'.
8+
9+
⚠️ RECOMMENDED: Use 'npm run commit' to create commit messages interactively, ensuring compliance.
10+
511
## Step 1: Planning (PLAN MODE)
612
- What problem does this tool solve?
713
- What API/service will it use?

‎.github/workflows/release.yml

+47
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
name: Release Automation
2+
3+
on:
4+
workflow_dispatch: # Allows manual triggering for testing
5+
6+
permissions:
7+
contents: write # Allows pushing commits/tags and creating releases
8+
9+
jobs:
10+
release:
11+
runs-on: ubuntu-latest
12+
steps:
13+
- name: Checkout code
14+
uses: actions/checkout@v3
15+
with:
16+
fetch-depth: 0 # Fetch all history for standard-version
17+
token: ${{ secrets.GITHUB_TOKEN }}
18+
19+
- name: Setup Node.js
20+
uses: actions/setup-node@v3
21+
with:
22+
node-version: 'lts/*' # Use the project's LTS Node version
23+
24+
- name: Install Dependencies
25+
run: npm ci
26+
27+
- name: Configure Git
28+
run: |
29+
git config user.name "github-actions[bot]"
30+
git config user.email "github-actions[bot]@users.noreply.github.com"
31+
32+
- name: Create Release Bump and Changelog
33+
run: npm run release -- --commit-all # standard-version determines version based on commits
34+
# Add --first-release if this is the absolute first tag/release
35+
36+
- name: Push changes and tags
37+
run: git push --follow-tags origin main
38+
# Ensure this pushes to the correct branch (e.g., main)
39+
40+
- name: Create GitHub Release
41+
uses: softprops/action-gh-release@v1
42+
# This action runs implicitly on tag push, which is handled by the previous step.
43+
# If you want more control, you can extract the tag version and trigger explicitly.
44+
env:
45+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
46+
with:
47+
generate_release_notes: true # Use conventional commits for release notes

‎.husky/commit-msg

+4
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
#!/usr/bin/env sh
2+
. "$(dirname -- "$0")/_/husky.sh"
3+
4+
npx --no -- commitlint --edit "$1"

‎CONTRIBUTING.md

+103
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
# Contributing to Azure DevOps MCP Server
2+
3+
We love your input! We want to make contributing to Azure DevOps MCP Server as easy and transparent as possible, whether it's:
4+
5+
- Reporting a bug
6+
- Discussing the current state of the code
7+
- Submitting a fix
8+
- Proposing new features
9+
- Becoming a maintainer
10+
11+
## Development Process
12+
13+
We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
14+
15+
## Pull Requests
16+
17+
1. Fork the repository
18+
2. Create your feature branch (`git checkout -b feature/amazing-feature`)
19+
3. Commit your changes (see Commit Message Guidelines below)
20+
4. Push to the branch (`git push origin feature/amazing-feature`)
21+
5. Open a Pull Request
22+
23+
## Commit Message Guidelines
24+
25+
We follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for our commit messages. This leads to more readable messages that are easy to follow when looking through the project history and enables automatic versioning and changelog generation.
26+
27+
### Commit Message Format
28+
29+
Each commit message consists of a **header**, a **body**, and a **footer**. The header has a special format that includes a **type**, a **scope**, and a **subject**:
30+
31+
```
32+
<type>(<scope>): <subject>
33+
<BLANK LINE>
34+
<body>
35+
<BLANK LINE>
36+
<footer>
37+
```
38+
39+
The **header** is mandatory, while the **scope** of the header is optional.
40+
41+
### Type
42+
43+
Must be one of the following:
44+
45+
- **feat**: A new feature
46+
- **fix**: A bug fix
47+
- **docs**: Documentation only changes
48+
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
49+
- **refactor**: A code change that neither fixes a bug nor adds a feature
50+
- **perf**: A code change that improves performance
51+
- **test**: Adding missing tests or correcting existing tests
52+
- **build**: Changes that affect the build system or external dependencies
53+
- **ci**: Changes to our CI configuration files and scripts
54+
- **chore**: Other changes that don't modify src or test files
55+
56+
### Subject
57+
58+
The subject contains a succinct description of the change:
59+
60+
- Use the imperative, present tense: "change" not "changed" nor "changes"
61+
- Don't capitalize the first letter
62+
- No period (.) at the end
63+
64+
### Body
65+
66+
The body should include the motivation for the change and contrast this with previous behavior.
67+
68+
### Footer
69+
70+
The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit closes.
71+
72+
Breaking Changes should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
73+
74+
### Using the Interactive Tool
75+
76+
To simplify the process of creating correctly formatted commit messages, we've set up a tool that will guide you through the process. Simply use:
77+
78+
```bash
79+
npm run commit
80+
```
81+
82+
This will start an interactive prompt that will help you generate a properly formatted commit message.
83+
84+
## Automated Release Workflow
85+
86+
Our project uses an automated release workflow that leverages Conventional Commits to manage semantic versioning, generate changelogs, and create GitHub Releases.
87+
88+
The workflow is currently triggered manually via GitHub Actions' `workflow_dispatch` feature. In the future, it may be configured to run automatically on merges to the `main` branch.
89+
90+
When the workflow runs, it:
91+
92+
1. Analyzes the commit messages since the last release
93+
2. Determines the appropriate semantic version bump
94+
3. Updates the version in package.json
95+
4. Generates or updates the CHANGELOG.md file
96+
5. Creates a new Git tag
97+
6. Creates a GitHub Release with release notes
98+
99+
This automation ensures consistent and well-documented releases that accurately reflect the changes made since the previous release.
100+
101+
## License
102+
103+
By contributing, you agree that your contributions will be licensed under the project's license.

0 commit comments

Comments
 (0)