Skip to content

Commit 2572180

Browse files
shuyanglishuyangli
authored
Initial version (#1)
* Initial version * Use tensorzero email for CI bot * Some minor config fixes * Update README * Repackage * Pin linter to v8.1.0 for now
1 parent 59662d1 commit 2572180

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

64 files changed

+111060
-0
lines changed

‎.env.example‎

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# dotenv-linter:off IncorrectDelimiter
2+
3+
# Do not commit your actual .env file to Git! This may contain secrets or other
4+
# private information.
5+
6+
# Enable/disable step debug logging (default: `false`). For local debugging, it
7+
# may be useful to set it to `true`.
8+
ACTIONS_STEP_DEBUG=true
9+
10+
# GitHub Actions inputs should follow `INPUT_<name>` format (case-sensitive).
11+
# Hyphens should not be converted to underscores!
12+
INPUT_MILLISECONDS=2400
13+
14+
# GitHub Actions default environment variables. These are set for every run of a
15+
# workflow and can be used in your actions. Setting the value here will override
16+
# any value set by the local-action tool.
17+
# https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
18+
19+
# CI="true"
20+
# GITHUB_ACTION=""
21+
# GITHUB_ACTION_PATH=""
22+
# GITHUB_ACTION_REPOSITORY=""
23+
# GITHUB_ACTIONS=""
24+
# GITHUB_ACTOR=""
25+
# GITHUB_ACTOR_ID=""
26+
# GITHUB_API_URL=""
27+
# GITHUB_BASE_REF=""
28+
# GITHUB_ENV=""
29+
# GITHUB_EVENT_NAME=""
30+
# GITHUB_EVENT_PATH=""
31+
# GITHUB_GRAPHQL_URL=""
32+
# GITHUB_HEAD_REF=""
33+
# GITHUB_JOB=""
34+
# GITHUB_OUTPUT=""
35+
# GITHUB_PATH=""
36+
# GITHUB_REF=""
37+
# GITHUB_REF_NAME=""
38+
# GITHUB_REF_PROTECTED=""
39+
# GITHUB_REF_TYPE=""
40+
# GITHUB_REPOSITORY=""
41+
# GITHUB_REPOSITORY_ID=""
42+
# GITHUB_REPOSITORY_OWNER=""
43+
# GITHUB_REPOSITORY_OWNER_ID=""
44+
# GITHUB_RETENTION_DAYS=""
45+
# GITHUB_RUN_ATTEMPT=""
46+
# GITHUB_RUN_ID=""
47+
# GITHUB_RUN_NUMBER=""
48+
# GITHUB_SERVER_URL=""
49+
# GITHUB_SHA=""
50+
# GITHUB_STEP_SUMMARY=""
51+
# GITHUB_TRIGGERING_ACTOR=""
52+
# GITHUB_WORKFLOW=""
53+
# GITHUB_WORKFLOW_REF=""
54+
# GITHUB_WORKFLOW_SHA=""
55+
# GITHUB_WORKSPACE=""
56+
# RUNNER_ARCH=""
57+
# RUNNER_DEBUG=""
58+
# RUNNER_NAME=""
59+
# RUNNER_OS=""
60+
# RUNNER_TEMP=""
61+
# RUNNER_TOOL_CACHE=""

‎.gitattributes‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
* text=auto eol=lf
2+
3+
dist/** -diff linguist-generated=true

‎.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: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
version: 2
2+
updates:
3+
- package-ecosystem: github-actions
4+
directory: /
5+
schedule:
6+
interval: weekly
7+
groups:
8+
actions-minor:
9+
update-types:
10+
- minor
11+
- patch
12+
13+
- package-ecosystem: npm
14+
directory: /
15+
schedule:
16+
interval: weekly
17+
groups:
18+
npm-development:
19+
dependency-type: development
20+
update-types:
21+
- minor
22+
- patch
23+
npm-production:
24+
dependency-type: production
25+
update-types:
26+
- patch

‎.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+
```

0 commit comments

Comments
 (0)