Skip to content

Commit fa45cbf

Browse files
committed
chore: Add Copilot instructions and prompts for changelog and release flow
1 parent 24f2a17 commit fa45cbf

File tree

4 files changed

+80
-2
lines changed

4 files changed

+80
-2
lines changed
Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
---
2+
applyTo: 'CHANGELOG.md'
3+
---
4+
5+
Do not edit the file unless explicitly requested by the user.
6+
When releasing a new version, you will be asked to create a new section in the `CHANGELOG.md` file for the version based on "Unreleased Changes".
7+
8+
# Style guidelines
9+
10+
- Use semantic versioning headings (e.g., ## <version>)
11+
- Release candidates are supported with version suffix format (e.g., `0.5.0-rc.1` should be labeled as "0.5.0 (Release Candidate 1)" in the changelog)
12+
- Do not use subheadings
13+
- Do not mention commit hashes
14+
- Write in past tense (e.g., "improved", "introduced", "added")
15+
- Balance technical accuracy with user-facing language
16+
- Use bullet points for individual changes
17+
18+
# Content guidelines
19+
20+
- Entries should be concise but can include technical details relevant to users
21+
- Write a bullet point for every new, changed, fixed, or removed feature
22+
- Do not use emojis
23+
- Include both user benefits and technical specifics when relevant
24+
25+
# Writing patterns
26+
27+
## Change descriptions
28+
29+
- **New tools/features**: "Added [tool/feature name] [brief description]"
30+
- **Improvements**: "Improved [component] to [specific enhancement]"
31+
- **Bug fixes**: "Fixed [issue description]" or "Fixed: [specific problem]"
32+
- **Removals**: "Removed [item] [reason if relevant]"
33+
- **Technical changes**: Include scope changes, API modifications, and architectural improvements
34+
35+
## User-centric language
36+
37+
- Emphasize user capabilities: "You can now...", "You will now find...", "It is now possible to..."
38+
- Explain business value: "enabling more precise...", "providing greater flexibility...", "ensuring smoother performance..."
39+
- Use positive framing: "enhanced", "improved", "better", "more accurate"
40+
41+
## Technical details to include
42+
43+
- Tool additions, modifications, and removals
44+
- Scope changes and OAuth permissions
45+
- API endpoint changes that affect users
46+
- Performance improvements with specific impacts
47+
- Breaking changes with migration guidance

.github/prompts/release.prompt.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
mode: agent
3+
---
4+
5+
# Release Instructions
6+
7+
When preparing a release, follow these steps to ensure everything is in order:
8+
9+
1. Go to the main branch and pull the latest changes. If dependencies changed, run `npm ci`.
10+
2. Ask the user what the new version number should be. It should follow semantic versioning, but it may have a suffix for release candidates.
11+
3. Work on a release branch, typically named `chore/prepare-release-<version>`.
12+
4. Create a new section in CHANGELOG.md for the version below "Unreleased Changes".
13+
5. Move all entries from "Unreleased Changes" to this new section. Reword them in the process to fit the content guidelines specified in `.github/instructions/changelog.instructions.md`.
14+
6. Update the version number in `package.json`.
15+
7. Run `npm install --package-lock-only` to sync the lock file.
16+
8. Let the user verify the release notes and version number before proceeding.
17+
9. Commit the changes with a message like `chore(release): prepare for <version> release`.

README.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -554,6 +554,20 @@ Third, create a `.env` file in this repository (you can copy from `.env.template
554554

555555
Finally, make changes to your code and compile it with `npm run build` or just run `npm run watch` and it auto-compiles.
556556

557+
## Releasing
558+
559+
When you are preparing for a release, you can use GitHub Copilot to guide you through the preparations.
560+
561+
In Visual Studio Code, you can use `/release` in the chat with Copilot in Agent Mode, which will execute [release.prompt.md](.github/prompts/release.prompt.md).
562+
563+
You may include additional information such as the version number. If not specified, you will be asked.
564+
565+
This will
566+
567+
- prepare the [changelog](CHANGELOG.md),
568+
- update the version number in [package.json](package.json),
569+
- commit the changes.
570+
557571
## Notes
558572

559573
This product is not officially supported by Dynatrace.

src/authentication/dynatrace-clients.test.ts

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -73,7 +73,7 @@ describe('dynatrace-clients', () => {
7373
baseUrl: environmentUrl,
7474
defaultHeaders: {
7575
'Authorization': 'Bearer test-access-token',
76-
'User-Agent': 'dynatrace-mcp-server/v1.0.0-test (linux-x64)',
76+
'User-Agent': expect.stringMatching(/^dynatrace-mcp-server\/v1\.0\.0-test \(\w+-\w+\)$/),
7777
},
7878
});
7979
expect(result).toBeInstanceOf(PlatformHttpClient);
@@ -172,7 +172,7 @@ describe('dynatrace-clients', () => {
172172
baseUrl: environmentUrl,
173173
defaultHeaders: {
174174
'Authorization': `Bearer ${dtPlatformToken}`,
175-
'User-Agent': 'dynatrace-mcp-server/v1.0.0-test (linux-x64)',
175+
'User-Agent': expect.stringMatching(/^dynatrace-mcp-server\/v1\.0\.0-test \(\w+-\w+\)$/),
176176
},
177177
});
178178
expect(result).toBeInstanceOf(PlatformHttpClient);

0 commit comments

Comments
 (0)