Skip to content

Commit 2aba37f

Browse files
ncalteenncalteen
authored
Merge pull request #1080 from actions/ncalteen/copilot
Add Copilot Configuration
2 parents cbfe00a + e11c7a8 commit 2aba37f

File tree

12 files changed

+314
-28
lines changed

12 files changed

+314
-28
lines changed

‎.github/codeql/codeql-config.yml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
name: JavaScript CodeQL Configuration
2+
3+
paths-ignore:
4+
- node_modules
5+
- dist

‎.github/copilot-instructions.md

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
# Copilot Instructions
2+
3+
This GitHub Action is written in TypeScript and transpiled to JavaScript. Both
4+
the TypeScript sources and the **generated** JavaScript code are contained in
5+
this repository. The TypeScript sources are contained in the `src` directory and
6+
the JavaScript code is contained in the `dist` directory. A GitHub Actions
7+
workflow checks that the JavaScript code in `dist` is up-to-date. Therefore, you
8+
should not review any changes to the contents of the `dist` folder and it is
9+
expected that the JavaScript code in `dist` closely mirrors the TypeScript code
10+
it is generated from.
11+
12+
## Repository Structure
13+
14+
| Path | Description |
15+
| ---------------------- | -------------------------------------------------------- |
16+
| `__fixtures__/` | Unit Test Fixtures |
17+
| `__tests__/` | Unit Tests |
18+
| `.devcontainer/` | Development Container Configuration |
19+
| `.github/` | GitHub Configuration |
20+
| `.licenses/` | License Information |
21+
| `.vscode/` | Visual Studio Code Configuration |
22+
| `badges/` | Badges for readme |
23+
| `dist/` | Generated JavaScript Code |
24+
| `src/` | TypeScript Source Code |
25+
| `.env.example` | Environment Variables Example for `@github/local-action` |
26+
| `.licensed.yml` | Licensed Configuration |
27+
| `.markdown-lint.yml` | Markdown Linter Configuration |
28+
| `.node-version` | Node.js Version Configuration |
29+
| `.prettierrc.yml` | Prettier Formatter Configuration |
30+
| `.yaml-lint.yml` | YAML Linter Configuration |
31+
| `action.yml` | GitHub Action Metadata |
32+
| `CODEOWNERS` | Code Owners File |
33+
| `eslint.config.mjs` | ESLint Configuration |
34+
| `jest.config.js` | Jest Configuration |
35+
| `LICENSE` | License File |
36+
| `package.json` | NPM Package Configuration |
37+
| `README.md` | Project Documentation |
38+
| `rollup.config.ts` | Rollup Bundler Configuration |
39+
| `tsconfig.base.json` | Base TypeScript Configuration |
40+
| `tsconfig.eslint.json` | TypeScript Configuration for ESLint |
41+
| `tsconfig.json` | TypeScript Configuration |
42+
43+
## Environment Setup
44+
45+
Install dependencies by running:
46+
47+
```bash
48+
npm install
49+
```
50+
51+
## Testing
52+
53+
Ensure all unit tests pass by running:
54+
55+
```bash
56+
npm run test
57+
```
58+
59+
Unit tests should exist in the `__tests__` directory. They are powered by
60+
`jest`. Fixtures should be placed in the `__fixtures__` directory.
61+
62+
## Bundling
63+
64+
Any time files in the `src` directory are changed, you should run the following
65+
command to bundle the TypeScript code into JavaScript:
66+
67+
```bash
68+
npm run bundle
69+
```
70+
71+
## General Coding Guidelines
72+
73+
- Follow standard TypeScript and JavaScript coding conventions and best
74+
practices
75+
- Changes should maintain consistency with existing patterns and style
76+
- Document changes clearly and thoroughly, including updates to existing
77+
comments when appropriate
78+
- Do not include basic, unnecessary comments that simply restate what the code
79+
is doing (focus on explaining _why_, not _what_)
80+
- Use consistent error handling patterns throughout the codebase
81+
- Use TypeScript's type system to ensure type safety and clarity
82+
- Keep functions focused and manageable
83+
- Use descriptive variable and function names that clearly convey their purpose
84+
- Use JSDoc comments to document functions, classes, and complex logic
85+
- After doing any refactoring, ensure to run `npm run test` to ensure that all
86+
tests still pass and coverage requirements are met
87+
- When suggesting code changes, always opt for the most maintainable approach.
88+
Try your best to keep the code clean and follow "Don't Repeat Yourself" (DRY)
89+
principles
90+
- Avoid unnecessary complexity and always consider the long-term maintainability
91+
of the code
92+
- When writing unit tests, try to consider edge cases as well as the main path
93+
of success. This will help ensure that the code is robust and can handle
94+
unexpected inputs or situations
95+
- Use the `@actions/core` package for logging over `console` to ensure
96+
compatibility with GitHub Actions logging features
97+
98+
### Versioning
99+
100+
GitHub Actions are versioned using branch and tag names. Please ensure the
101+
version in the project's `package.json` is updated to reflect the changes made
102+
in the codebase. The version should follow
103+
[Semantic Versioning](https://semver.org/) principles.
104+
105+
## Pull Request Guidelines
106+
107+
When creating a pull request (PR), please ensure that:
108+
109+
- Keep changes focused and minimal (avoid large changes, or consider breaking
110+
them into separate, smaller PRs)
111+
- Formatting checks pass
112+
- Linting checks pass
113+
- Unit tests pass and coverage requirements are met
114+
- The action has been transpiled to JavaScript and the `dist` directory is
115+
up-to-date with the latest changes in the `src` directory
116+
- If necessary, the `README.md` file is updated to reflect any changes in
117+
functionality or usage
118+
119+
The body of the PR should include:
120+
121+
- A summary of the changes
122+
- A special note of any changes to dependencies
123+
- A link to any relevant issues or discussions
124+
- Any additional context that may be helpful for reviewers
125+
126+
## Code Review Guidelines
127+
128+
When performing a code review, please follow these guidelines:
129+
130+
- If there are changes that modify the functionality/usage of the action,
131+
validate that there are changes in the `README.md` file that document the new
132+
or modified functionality

‎.github/dependabot.yml

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,10 +14,6 @@ updates:
1414
directory: /
1515
schedule:
1616
interval: weekly
17-
ignore:
18-
- dependency-name: '@types/node'
19-
update-types:
20-
- 'version-update:semver-major'
2117
groups:
2218
npm-development:
2319
dependency-type: development

‎.github/prompts/create-release-notes.prompt.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Create Release Notes
2+
3+
You are an expert technical writer tasked with creating release notes for
4+
updates to this repository. Your specific task is to generate release notes that
5+
are clear, concise, and useful for developers and users of the project.
6+
7+
## Guidelines
8+
9+
Ensure you adhere to the following guidelines when creating release notes:
10+
11+
- Use a clear and consistent format for the release notes
12+
- Include a summary of the changes made in the release
13+
- Highlight any new features, improvements, or bugfixes
14+
- If applicable, include instructions for upgrading or migrating to the new
15+
version
16+
- Use technical language that is appropriate for the audience, but avoid jargon
17+
that may not be understood by all users
18+
- Ensure that the release notes are easy to read and navigate
19+
- Include relevant issue or PR numbers where applicable
20+
- Use proper Markdown formatting
21+
- Use code blocks for commands, configuration examples, or code changes
22+
- Use note and warning callouts for important information
23+
24+
## Versioning
25+
26+
GitHub Actions are versioned using branch and tag names. The version in the
27+
project's `package.json` should reflect the changes made in the codebase and
28+
follow [Semantic Versioning](https://semver.org/) principles. Depending on the
29+
nature of the changes, please make sure to adjust the release notes accordingly:
30+
31+
- For **major** changes, include a detailed description of the breaking changes
32+
and how users can adapt to them
33+
- For **minor** changes, highlight new features and improvements
34+
- For **patch** changes, focus on bugfixes and minor improvements

‎.github/prompts/unit-test.prompt.md

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
# Create Unit Test(s)
2+
3+
You are an expert software engineer tasked with creating unit tests for the
4+
repository. Your specific task is to generate unit tests that are clear,
5+
concise, and useful for developers working on the project.
6+
7+
## Guidelines
8+
9+
Ensure you adhere to the following guidelines when creating unit tests:
10+
11+
- Use a clear and consistent format for the unit tests
12+
- Include a summary of the functionality being tested
13+
- Use descriptive test names that clearly convey their purpose
14+
- Ensure tests cover both the main path of success and edge cases
15+
- Use proper assertions to validate the expected outcomes
16+
- Use `jest` for writing and running tests
17+
- Place unit tests in the `__tests__` directory
18+
- Use fixtures for any necessary test data, placed in the `__fixtures__`
19+
directory
20+
21+
## Example
22+
23+
Use the following as an example of how to structure your unit tests:
24+
25+
```typescript
26+
/**
27+
* Unit tests for the action's main functionality, src/main.ts
28+
*/
29+
import { jest } from '@jest/globals'
30+
import * as core from '../__fixtures__/core.js'
31+
import { wait } from '../__fixtures__/wait.js'
32+
33+
// Mocks should be declared before the module being tested is imported.
34+
jest.unstable_mockModule('@actions/core', () => core)
35+
jest.unstable_mockModule('../src/wait.js', () => ({ wait }))
36+
37+
// The module being tested should be imported dynamically. This ensures that the
38+
// mocks are used in place of any actual dependencies.
39+
const { run } = await import('../src/main.js')
40+
41+
describe('main.ts', () => {
42+
beforeEach(() => {
43+
// Set the action's inputs as return values from core.getInput().
44+
core.getInput.mockImplementation(() => '500')
45+
46+
// Mock the wait function so that it does not actually wait.
47+
wait.mockImplementation(() => Promise.resolve('done!'))
48+
})
49+
50+
afterEach(() => {
51+
jest.resetAllMocks()
52+
})
53+
54+
it('Sets the time output', async () => {
55+
await run()
56+
57+
// Verify the time output was set.
58+
expect(core.setOutput).toHaveBeenNthCalledWith(
59+
1,
60+
'time',
61+
// Simple regex to match a time string in the format HH:MM:SS.
62+
expect.stringMatching(/^\d{2}:\d{2}:\d{2}/)
63+
)
64+
})
65+
66+
it('Sets a failed status', async () => {
67+
// Clear the getInput mock and return an invalid value.
68+
core.getInput.mockClear().mockReturnValueOnce('this is not a number')
69+
70+
// Clear the wait mock and return a rejected promise.
71+
wait
72+
.mockClear()
73+
.mockRejectedValueOnce(new Error('milliseconds is not a number'))
74+
75+
await run()
76+
77+
// Verify that the action was marked as failed.
78+
expect(core.setFailed).toHaveBeenNthCalledWith(
79+
1,
80+
'milliseconds is not a number'
81+
)
82+
})
83+
})
84+
```

‎.github/workflows/codeql-analysis.yml

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ jobs:
2525
fail-fast: false
2626
matrix:
2727
language:
28-
- TypeScript
28+
- typescript
2929

3030
steps:
3131
- name: Checkout
@@ -36,6 +36,7 @@ jobs:
3636
id: initialize
3737
uses: github/codeql-action/init@v3
3838
with:
39+
config-file: .github/codeql/codeql-config.yml
3940
languages: ${{ matrix.language }}
4041
source-root: src
4142

‎.github/workflows/linter.yml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,8 @@
1+
# This workflow will lint the entire codebase using the
2+
# `super-linter/super-linter` action.
3+
#
4+
# For more information, see the super-linter repository:
5+
# https://github.com/super-linter/super-linter
16
name: Lint Codebase
27

38
on:

‎.vscode/mcp.json

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
{
2+
"servers": {
3+
"github": {
4+
"url": "https://api.githubcopilot.com/mcp/",
5+
"type": "http"
6+
}
7+
},
8+
"inputs": []
9+
}

‎.vscode/settings.json

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
{
2+
"github.copilot.chat.reviewSelection.instructions": [
3+
{
4+
"text": "Review the code changes carefully before accepting them."
5+
}
6+
],
7+
"github.copilot.chat.commitMessageGeneration.instructions": [
8+
{
9+
"text": "Use conventional commit message format."
10+
}
11+
],
12+
"github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
13+
{ "text": "Always include a list of key changes." }
14+
]
15+
}

‎README.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -106,7 +106,7 @@ There are a few things to keep in mind when writing your action code:
106106
```
107107

108108
For more information about the GitHub Actions toolkit, see the
109-
[documentation](https://github.com/actions/toolkit/blob/master/README.md).
109+
[documentation](https://github.com/actions/toolkit/blob/main/README.md).
110110

111111
So, what are you waiting for? Go ahead and start customizing your action!
112112

@@ -138,6 +138,7 @@ So, what are you waiting for? Go ahead and start customizing your action!
138138
to a repository.
139139

140140
The `local-action` utility can be run in the following ways:
141+
141142
- Visual Studio Code Debugger
142143

143144
Make sure to review and, if needed, update
@@ -175,7 +176,7 @@ So, what are you waiting for? Go ahead and start customizing your action!
175176
Your action is now published! :rocket:
176177

177178
For information about versioning your action, see
178-
[Versioning](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md)
179+
[Versioning](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md)
179180
in the GitHub Actions toolkit.
180181

181182
## Validate the Action
@@ -208,7 +209,7 @@ For example workflow runs, check out the
208209

209210
After testing, you can create version tag(s) that developers can use to
210211
reference different stable versions of your action. For more information, see
211-
[Versioning](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md)
212+
[Versioning](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md)
212213
in the GitHub Actions toolkit.
213214

214215
To include the action in a workflow in another repository, you can use the

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy