feat(workflows): create 'test.yml' reusable workflow

[oscard0m]

Resolves #49

---

Behavior

Before the change?

• Each of Octokit's repositories has their own copy of test.yml for the CI tests.

After the change?

• We create a common workflow for CI tests all Octokit's repositories will be able to re-use.

Other information

#49

---

Additional info

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Added the appropriate label for the given change

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes (Please add the Type: Breaking change label)
• No

If Yes, what's the impact:

• N/A

Pull request type

Type: Feature

---

[timrogers]

Thanks for taking the time to work on this ❤️

The custom steps is a hard problem. What proportion of repos/workflows have custom steps outside of this framework?

[timrogers]

What do you think of renaming this job to be more indicative?

Suggested change

	test:
	lint:

[gr2m]

it's not just linting, we also test things that are independent of node versions, e.g. type tests

[timrogers]

Interesting! Does the lint npm script do all of those things? (I made this suggestion because the only substantive command in the steps is to run the lint script.)

[gr2m]

What approach do we want to follow for custom steps?5

1. Extra custom-test workflows which extend a generic test.yml?
2. Add extra logic to `test.yml` to give support to all the use cases?

I'd prefer option 2., I don't think there should be too many different tasks across the JS octokit/* repositories.

[wolfy1339]

octokit/webhooks has many different tasks
The equivalent test job is called npmCi in this case

[gr2m]

Maybe we only use the reusable test.yml workflow for octokit/*.{js,ts} repositories?

We could also create a setup composite action which only runs actions/checkout and actions/setup-node? It will make our builds a bit slower because the extra action would need to be checked out, but I don't think it'll take a lot.

I think we should be able to add the action.yml file into the .github folder at a path such as actions/setup and then utilize it like this

  - uses: ocotkit/.github/actions/setup

See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-a-public-action-in-a-subdirectory

[gr2m]

I see some repositories using npm run build

I'd always run it with npm run build --if-present, just like the others. This makes sure that we verify that the dependencies only used for building are tested as part of the CI

• npm run validate:ts
• npm run test:typescript
• npm run test:ts

I'm tending towards test:tsc to be as clear as possible. In other project I use test:tsd for type-only tests using tsd, and in future when I hope me move away from TS source code I could imagine @octokit to use that, too (Example)

But I'm open to anything, it's not set in stone. I do agree we should normalize it across the @octokit repositories though

[wolfy1339]

@oscard0m Do you have any updates on this