mirror of
https://github.com/actions/typescript-action.git
synced 2025-12-13 21:51:53 +00:00
Merge pull request #1080 from actions/ncalteen/copilot
Add Copilot Configuration
This commit is contained in:
5
.github/codeql/codeql-config.yml
vendored
Normal file
5
.github/codeql/codeql-config.yml
vendored
Normal file
@@ -0,0 +1,5 @@
|
||||
name: JavaScript CodeQL Configuration
|
||||
|
||||
paths-ignore:
|
||||
- node_modules
|
||||
- dist
|
||||
132
.github/copilot-instructions.md
vendored
Normal file
132
.github/copilot-instructions.md
vendored
Normal file
@@ -0,0 +1,132 @@
|
||||
# Copilot Instructions
|
||||
|
||||
This GitHub Action is written in TypeScript and transpiled to JavaScript. Both
|
||||
the TypeScript sources and the **generated** JavaScript code are contained in
|
||||
this repository. The TypeScript sources are contained in the `src` directory and
|
||||
the JavaScript code is contained in the `dist` directory. A GitHub Actions
|
||||
workflow checks that the JavaScript code in `dist` is up-to-date. Therefore, you
|
||||
should not review any changes to the contents of the `dist` folder and it is
|
||||
expected that the JavaScript code in `dist` closely mirrors the TypeScript code
|
||||
it is generated from.
|
||||
|
||||
## Repository Structure
|
||||
|
||||
| Path | Description |
|
||||
| ---------------------- | -------------------------------------------------------- |
|
||||
| `__fixtures__/` | Unit Test Fixtures |
|
||||
| `__tests__/` | Unit Tests |
|
||||
| `.devcontainer/` | Development Container Configuration |
|
||||
| `.github/` | GitHub Configuration |
|
||||
| `.licenses/` | License Information |
|
||||
| `.vscode/` | Visual Studio Code Configuration |
|
||||
| `badges/` | Badges for readme |
|
||||
| `dist/` | Generated JavaScript Code |
|
||||
| `src/` | TypeScript Source Code |
|
||||
| `.env.example` | Environment Variables Example for `@github/local-action` |
|
||||
| `.licensed.yml` | Licensed Configuration |
|
||||
| `.markdown-lint.yml` | Markdown Linter Configuration |
|
||||
| `.node-version` | Node.js Version Configuration |
|
||||
| `.prettierrc.yml` | Prettier Formatter Configuration |
|
||||
| `.yaml-lint.yml` | YAML Linter Configuration |
|
||||
| `action.yml` | GitHub Action Metadata |
|
||||
| `CODEOWNERS` | Code Owners File |
|
||||
| `eslint.config.mjs` | ESLint Configuration |
|
||||
| `jest.config.js` | Jest Configuration |
|
||||
| `LICENSE` | License File |
|
||||
| `package.json` | NPM Package Configuration |
|
||||
| `README.md` | Project Documentation |
|
||||
| `rollup.config.ts` | Rollup Bundler Configuration |
|
||||
| `tsconfig.base.json` | Base TypeScript Configuration |
|
||||
| `tsconfig.eslint.json` | TypeScript Configuration for ESLint |
|
||||
| `tsconfig.json` | TypeScript Configuration |
|
||||
|
||||
## Environment Setup
|
||||
|
||||
Install dependencies by running:
|
||||
|
||||
```bash
|
||||
npm install
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
||||
Ensure all unit tests pass by running:
|
||||
|
||||
```bash
|
||||
npm run test
|
||||
```
|
||||
|
||||
Unit tests should exist in the `__tests__` directory. They are powered by
|
||||
`jest`. Fixtures should be placed in the `__fixtures__` directory.
|
||||
|
||||
## Bundling
|
||||
|
||||
Any time files in the `src` directory are changed, you should run the following
|
||||
command to bundle the TypeScript code into JavaScript:
|
||||
|
||||
```bash
|
||||
npm run bundle
|
||||
```
|
||||
|
||||
## General Coding Guidelines
|
||||
|
||||
- Follow standard TypeScript and JavaScript coding conventions and best
|
||||
practices
|
||||
- Changes should maintain consistency with existing patterns and style
|
||||
- Document changes clearly and thoroughly, including updates to existing
|
||||
comments when appropriate
|
||||
- Do not include basic, unnecessary comments that simply restate what the code
|
||||
is doing (focus on explaining _why_, not _what_)
|
||||
- Use consistent error handling patterns throughout the codebase
|
||||
- Use TypeScript's type system to ensure type safety and clarity
|
||||
- Keep functions focused and manageable
|
||||
- Use descriptive variable and function names that clearly convey their purpose
|
||||
- Use JSDoc comments to document functions, classes, and complex logic
|
||||
- After doing any refactoring, ensure to run `npm run test` to ensure that all
|
||||
tests still pass and coverage requirements are met
|
||||
- When suggesting code changes, always opt for the most maintainable approach.
|
||||
Try your best to keep the code clean and follow "Don't Repeat Yourself" (DRY)
|
||||
principles
|
||||
- Avoid unnecessary complexity and always consider the long-term maintainability
|
||||
of the code
|
||||
- When writing unit tests, try to consider edge cases as well as the main path
|
||||
of success. This will help ensure that the code is robust and can handle
|
||||
unexpected inputs or situations
|
||||
- Use the `@actions/core` package for logging over `console` to ensure
|
||||
compatibility with GitHub Actions logging features
|
||||
|
||||
### Versioning
|
||||
|
||||
GitHub Actions are versioned using branch and tag names. Please ensure the
|
||||
version in the project's `package.json` is updated to reflect the changes made
|
||||
in the codebase. The version should follow
|
||||
[Semantic Versioning](https://semver.org/) principles.
|
||||
|
||||
## Pull Request Guidelines
|
||||
|
||||
When creating a pull request (PR), please ensure that:
|
||||
|
||||
- Keep changes focused and minimal (avoid large changes, or consider breaking
|
||||
them into separate, smaller PRs)
|
||||
- Formatting checks pass
|
||||
- Linting checks pass
|
||||
- Unit tests pass and coverage requirements are met
|
||||
- The action has been transpiled to JavaScript and the `dist` directory is
|
||||
up-to-date with the latest changes in the `src` directory
|
||||
- If necessary, the `README.md` file is updated to reflect any changes in
|
||||
functionality or usage
|
||||
|
||||
The body of the PR should include:
|
||||
|
||||
- A summary of the changes
|
||||
- A special note of any changes to dependencies
|
||||
- A link to any relevant issues or discussions
|
||||
- Any additional context that may be helpful for reviewers
|
||||
|
||||
## Code Review Guidelines
|
||||
|
||||
When performing a code review, please follow these guidelines:
|
||||
|
||||
- If there are changes that modify the functionality/usage of the action,
|
||||
validate that there are changes in the `README.md` file that document the new
|
||||
or modified functionality
|
||||
4
.github/dependabot.yml
vendored
4
.github/dependabot.yml
vendored
@@ -14,10 +14,6 @@ updates:
|
||||
directory: /
|
||||
schedule:
|
||||
interval: weekly
|
||||
ignore:
|
||||
- dependency-name: '@types/node'
|
||||
update-types:
|
||||
- 'version-update:semver-major'
|
||||
groups:
|
||||
npm-development:
|
||||
dependency-type: development
|
||||
|
||||
34
.github/prompts/create-release-notes.prompt.md
vendored
Normal file
34
.github/prompts/create-release-notes.prompt.md
vendored
Normal file
@@ -0,0 +1,34 @@
|
||||
# Create Release Notes
|
||||
|
||||
You are an expert technical writer tasked with creating release notes for
|
||||
updates to this repository. Your specific task is to generate release notes that
|
||||
are clear, concise, and useful for developers and users of the project.
|
||||
|
||||
## Guidelines
|
||||
|
||||
Ensure you adhere to the following guidelines when creating release notes:
|
||||
|
||||
- Use a clear and consistent format for the release notes
|
||||
- Include a summary of the changes made in the release
|
||||
- Highlight any new features, improvements, or bugfixes
|
||||
- If applicable, include instructions for upgrading or migrating to the new
|
||||
version
|
||||
- Use technical language that is appropriate for the audience, but avoid jargon
|
||||
that may not be understood by all users
|
||||
- Ensure that the release notes are easy to read and navigate
|
||||
- Include relevant issue or PR numbers where applicable
|
||||
- Use proper Markdown formatting
|
||||
- Use code blocks for commands, configuration examples, or code changes
|
||||
- Use note and warning callouts for important information
|
||||
|
||||
## Versioning
|
||||
|
||||
GitHub Actions are versioned using branch and tag names. The version in the
|
||||
project's `package.json` should reflect the changes made in the codebase and
|
||||
follow [Semantic Versioning](https://semver.org/) principles. Depending on the
|
||||
nature of the changes, please make sure to adjust the release notes accordingly:
|
||||
|
||||
- For **major** changes, include a detailed description of the breaking changes
|
||||
and how users can adapt to them
|
||||
- For **minor** changes, highlight new features and improvements
|
||||
- For **patch** changes, focus on bugfixes and minor improvements
|
||||
84
.github/prompts/unit-test.prompt.md
vendored
Normal file
84
.github/prompts/unit-test.prompt.md
vendored
Normal file
@@ -0,0 +1,84 @@
|
||||
# Create Unit Test(s)
|
||||
|
||||
You are an expert software engineer tasked with creating unit tests for the
|
||||
repository. Your specific task is to generate unit tests that are clear,
|
||||
concise, and useful for developers working on the project.
|
||||
|
||||
## Guidelines
|
||||
|
||||
Ensure you adhere to the following guidelines when creating unit tests:
|
||||
|
||||
- Use a clear and consistent format for the unit tests
|
||||
- Include a summary of the functionality being tested
|
||||
- Use descriptive test names that clearly convey their purpose
|
||||
- Ensure tests cover both the main path of success and edge cases
|
||||
- Use proper assertions to validate the expected outcomes
|
||||
- Use `jest` for writing and running tests
|
||||
- Place unit tests in the `__tests__` directory
|
||||
- Use fixtures for any necessary test data, placed in the `__fixtures__`
|
||||
directory
|
||||
|
||||
## Example
|
||||
|
||||
Use the following as an example of how to structure your unit tests:
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* Unit tests for the action's main functionality, src/main.ts
|
||||
*/
|
||||
import { jest } from '@jest/globals'
|
||||
import * as core from '../__fixtures__/core.js'
|
||||
import { wait } from '../__fixtures__/wait.js'
|
||||
|
||||
// Mocks should be declared before the module being tested is imported.
|
||||
jest.unstable_mockModule('@actions/core', () => core)
|
||||
jest.unstable_mockModule('../src/wait.js', () => ({ wait }))
|
||||
|
||||
// The module being tested should be imported dynamically. This ensures that the
|
||||
// mocks are used in place of any actual dependencies.
|
||||
const { run } = await import('../src/main.js')
|
||||
|
||||
describe('main.ts', () => {
|
||||
beforeEach(() => {
|
||||
// Set the action's inputs as return values from core.getInput().
|
||||
core.getInput.mockImplementation(() => '500')
|
||||
|
||||
// Mock the wait function so that it does not actually wait.
|
||||
wait.mockImplementation(() => Promise.resolve('done!'))
|
||||
})
|
||||
|
||||
afterEach(() => {
|
||||
jest.resetAllMocks()
|
||||
})
|
||||
|
||||
it('Sets the time output', async () => {
|
||||
await run()
|
||||
|
||||
// Verify the time output was set.
|
||||
expect(core.setOutput).toHaveBeenNthCalledWith(
|
||||
1,
|
||||
'time',
|
||||
// Simple regex to match a time string in the format HH:MM:SS.
|
||||
expect.stringMatching(/^\d{2}:\d{2}:\d{2}/)
|
||||
)
|
||||
})
|
||||
|
||||
it('Sets a failed status', async () => {
|
||||
// Clear the getInput mock and return an invalid value.
|
||||
core.getInput.mockClear().mockReturnValueOnce('this is not a number')
|
||||
|
||||
// Clear the wait mock and return a rejected promise.
|
||||
wait
|
||||
.mockClear()
|
||||
.mockRejectedValueOnce(new Error('milliseconds is not a number'))
|
||||
|
||||
await run()
|
||||
|
||||
// Verify that the action was marked as failed.
|
||||
expect(core.setFailed).toHaveBeenNthCalledWith(
|
||||
1,
|
||||
'milliseconds is not a number'
|
||||
)
|
||||
})
|
||||
})
|
||||
```
|
||||
3
.github/workflows/codeql-analysis.yml
vendored
3
.github/workflows/codeql-analysis.yml
vendored
@@ -25,7 +25,7 @@ jobs:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
language:
|
||||
- TypeScript
|
||||
- typescript
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
@@ -36,6 +36,7 @@ jobs:
|
||||
id: initialize
|
||||
uses: github/codeql-action/init@v3
|
||||
with:
|
||||
config-file: .github/codeql/codeql-config.yml
|
||||
languages: ${{ matrix.language }}
|
||||
source-root: src
|
||||
|
||||
|
||||
5
.github/workflows/linter.yml
vendored
5
.github/workflows/linter.yml
vendored
@@ -1,3 +1,8 @@
|
||||
# This workflow will lint the entire codebase using the
|
||||
# `super-linter/super-linter` action.
|
||||
#
|
||||
# For more information, see the super-linter repository:
|
||||
# https://github.com/super-linter/super-linter
|
||||
name: Lint Codebase
|
||||
|
||||
on:
|
||||
|
||||
9
.vscode/mcp.json
vendored
Normal file
9
.vscode/mcp.json
vendored
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"servers": {
|
||||
"github": {
|
||||
"url": "https://api.githubcopilot.com/mcp/",
|
||||
"type": "http"
|
||||
}
|
||||
},
|
||||
"inputs": []
|
||||
}
|
||||
15
.vscode/settings.json
vendored
Normal file
15
.vscode/settings.json
vendored
Normal file
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"github.copilot.chat.reviewSelection.instructions": [
|
||||
{
|
||||
"text": "Review the code changes carefully before accepting them."
|
||||
}
|
||||
],
|
||||
"github.copilot.chat.commitMessageGeneration.instructions": [
|
||||
{
|
||||
"text": "Use conventional commit message format."
|
||||
}
|
||||
],
|
||||
"github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
|
||||
{ "text": "Always include a list of key changes." }
|
||||
]
|
||||
}
|
||||
@@ -106,7 +106,7 @@ There are a few things to keep in mind when writing your action code:
|
||||
```
|
||||
|
||||
For more information about the GitHub Actions toolkit, see the
|
||||
[documentation](https://github.com/actions/toolkit/blob/master/README.md).
|
||||
[documentation](https://github.com/actions/toolkit/blob/main/README.md).
|
||||
|
||||
So, what are you waiting for? Go ahead and start customizing your action!
|
||||
|
||||
@@ -138,6 +138,7 @@ So, what are you waiting for? Go ahead and start customizing your action!
|
||||
to a repository.
|
||||
|
||||
The `local-action` utility can be run in the following ways:
|
||||
|
||||
- Visual Studio Code Debugger
|
||||
|
||||
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!
|
||||
Your action is now published! :rocket:
|
||||
|
||||
For information about versioning your action, see
|
||||
[Versioning](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md)
|
||||
[Versioning](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md)
|
||||
in the GitHub Actions toolkit.
|
||||
|
||||
## Validate the Action
|
||||
@@ -208,7 +209,7 @@ For example workflow runs, check out the
|
||||
|
||||
After testing, you can create version tag(s) that developers can use to
|
||||
reference different stable versions of your action. For more information, see
|
||||
[Versioning](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md)
|
||||
[Versioning](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md)
|
||||
in the GitHub Actions toolkit.
|
||||
|
||||
To include the action in a workflow in another repository, you can use the
|
||||
|
||||
42
package-lock.json
generated
42
package-lock.json
generated
@@ -30,7 +30,7 @@
|
||||
"eslint-plugin-prettier": "^5.5.1",
|
||||
"jest": "^30.0.4",
|
||||
"make-coverage-badge": "^1.2.0",
|
||||
"prettier": "^3.6.2",
|
||||
"prettier": "^3.5.3",
|
||||
"prettier-eslint": "^16.4.2",
|
||||
"rollup": "^4.44.2",
|
||||
"ts-jest": "^29.4.0",
|
||||
@@ -5017,10 +5017,11 @@
|
||||
}
|
||||
},
|
||||
"node_modules/@typescript-eslint/typescript-estree/node_modules/brace-expansion": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
|
||||
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
|
||||
"version": "2.0.2",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.2.tgz",
|
||||
"integrity": "sha512-Jt0vHyM+jmUBqojB7E1NIYadt0vI0Qxjxd2TErW94wDz+E2LAm5vKMXXwg6ZZBTHPuUlDgQHKXvjGBdfcF1ZDQ==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"balanced-match": "^1.0.0"
|
||||
}
|
||||
@@ -5638,9 +5639,9 @@
|
||||
}
|
||||
},
|
||||
"node_modules/archiver-utils/node_modules/brace-expansion": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
|
||||
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
|
||||
"version": "2.0.2",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.2.tgz",
|
||||
"integrity": "sha512-Jt0vHyM+jmUBqojB7E1NIYadt0vI0Qxjxd2TErW94wDz+E2LAm5vKMXXwg6ZZBTHPuUlDgQHKXvjGBdfcF1ZDQ==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
@@ -6018,10 +6019,11 @@
|
||||
"license": "MIT"
|
||||
},
|
||||
"node_modules/brace-expansion": {
|
||||
"version": "1.1.11",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz",
|
||||
"integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==",
|
||||
"version": "1.1.12",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.12.tgz",
|
||||
"integrity": "sha512-9T9UjW3r0UW5c1Q7GTwllptXwhvYmEzFhzMfZ9H7FQWt+uZePjZPjBP/W1ZEyZ1twGWom5/56TF4lPcqjnDHcg==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"balanced-match": "^1.0.0",
|
||||
"concat-map": "0.0.1"
|
||||
@@ -7627,10 +7629,11 @@
|
||||
}
|
||||
},
|
||||
"node_modules/filelist/node_modules/brace-expansion": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
|
||||
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
|
||||
"version": "2.0.2",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.2.tgz",
|
||||
"integrity": "sha512-Jt0vHyM+jmUBqojB7E1NIYadt0vI0Qxjxd2TErW94wDz+E2LAm5vKMXXwg6ZZBTHPuUlDgQHKXvjGBdfcF1ZDQ==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"balanced-match": "^1.0.0"
|
||||
}
|
||||
@@ -12253,10 +12256,11 @@
|
||||
}
|
||||
},
|
||||
"node_modules/prettier": {
|
||||
"version": "3.6.2",
|
||||
"resolved": "https://registry.npmjs.org/prettier/-/prettier-3.6.2.tgz",
|
||||
"integrity": "sha512-I7AIg5boAr5R0FFtJ6rCfD+LFsWHp81dolrFD8S79U9tb8Az2nGrJncnMSnys+bpQJfRUzqs9hnA81OAA3hCuQ==",
|
||||
"version": "3.5.3",
|
||||
"resolved": "https://registry.npmjs.org/prettier/-/prettier-3.5.3.tgz",
|
||||
"integrity": "sha512-QQtaxnoDJeAkDvDKWCLiwIXkTgRhwYDEQCghU9Z6q03iyek/rxRh/2lC3HB7P8sWT2xC/y5JDctPLBIGzHKbhw==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"bin": {
|
||||
"prettier": "bin/prettier.cjs"
|
||||
},
|
||||
@@ -12680,9 +12684,9 @@
|
||||
}
|
||||
},
|
||||
"node_modules/readdir-glob/node_modules/brace-expansion": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
|
||||
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
|
||||
"version": "2.0.2",
|
||||
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.2.tgz",
|
||||
"integrity": "sha512-Jt0vHyM+jmUBqojB7E1NIYadt0vI0Qxjxd2TErW94wDz+E2LAm5vKMXXwg6ZZBTHPuUlDgQHKXvjGBdfcF1ZDQ==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
|
||||
@@ -58,7 +58,7 @@
|
||||
"eslint-plugin-prettier": "^5.5.1",
|
||||
"jest": "^30.0.4",
|
||||
"make-coverage-badge": "^1.2.0",
|
||||
"prettier": "^3.6.2",
|
||||
"prettier": "^3.5.3",
|
||||
"prettier-eslint": "^16.4.2",
|
||||
"rollup": "^4.44.2",
|
||||
"ts-jest": "^29.4.0",
|
||||
|
||||
Reference in New Issue
Block a user