Which GitHub Actions should be included

[lumirlumir]

I've gone through the entire ESLint repository and identified several workflows that would be valuable to manage in the centralized workflows repository.

Extracting common logic from these workflows will require further investigation, but I believe the following workflows are worth handling centrally.

I've marked the workflows with ✅ for those that are impactful, and ⚠️ for those that are ambiguous.

Any feedback is welcome! 😄 Here are some of the workflows:

1. renovate.json5 ✅

I think using automated dependency management could help improve the maintainability of our projects.

Currently, only two repositories are using it, but I believe it would be beneficial to use renovate across all repositories so we can take advantage of automated dependency updates.

Alternative

Another possible alternative is dependabot, which is maintained natively by GitHub. However, I think renovate offers more useful features, so I’m in favor of using renovate.

Used in

• https://github.com/eslint/rewrite/blob/main/.github/renovate.json5
• https://github.com/eslint/eslint/blob/main/.github/renovate.json5

2. add-to-triage.yml ✅

Related Issue: #5

add-to-triage.yml is a workflow that automatically moves issues and PRs to the Triage board, using the add-to-triage GitHub Action.

As mentioned in #5, currently only 5 projects are benefiting from automated project triaging.

Manually moving issues and PRs to the triage board takes time and effort, so I hope this can be included in this repository.

Used in

• https://github.com/eslint/markdown/blob/main/.github/workflows/add-to-triage.yml
• https://github.com/eslint/create-config/blob/main/.github/workflows/add-to-triage.yml
• https://github.com/eslint/generator-eslint/blob/main/.github/workflows/add-to-triage.yml
• https://github.com/eslint/zh-hans.docs.eslint.org/blob/latest/.github/workflows/add-to-triage.yml
• https://github.com/eslint/eslint-github-bot/blob/main/.github/workflows/add-to-triage.yml
• https://github.com/eslint/eslint-release/blob/main/.github/workflows/add-to-triage.yml

3. update-readme.yml ✅

Related Issue: #6

update-readme.yml is a workflow that automatically updates the README.md file and applies the latest sponsorship information.

Maintaining this workflow manually in every repository can cause a few issues:

• You need to create tools/commit-readme.sh, tools/update-readme.js, and .github/workflows/update-readme.yml in each repository.
• The got package must be installed just to update the sponsorship badge in the README.md.

Used in

• https://github.com/eslint/markdown/blob/main/.github/workflows/update-readme.yml
• https://github.com/eslint/json/blob/main/.github/workflows/update-readme.yml
• https://github.com/eslint/css/blob/main/.github/workflows/update-readme.yml
• https://github.com/eslint/rewrite/blob/main/.github/workflows/update-readme.yml
• https://github.com/eslint/eslint/blob/main/.github/workflows/update-readme.yml
• https://github.com/eslint/js/blob/main/.github/workflows/update-readme.yml
• https://github.com/eslint/code-explorer/blob/main/.github/workflows/update-readme.yml

4. bun-test.yml ✅

I think it's a good practice to test against various runtimes when developing libraries. I'd like to include this workflow in the centralized repository so it can be reused across different library repositories.

Used in

• https://github.com/eslint/markdown/blob/main/.github/workflows/bun-test.yml
• https://github.com/eslint/json/blob/main/.github/workflows/bun-test.yml
• https://github.com/eslint/css/blob/main/.github/workflows/bun-test.yml
• https://github.com/eslint/rewrite/blob/main/.github/workflows/bun-test.yml

5. ci-build-all-pm.yml ✅

Just like with bun-test.yml, I think it's a good practice to test against different package managers when developing libraries. I'd like to include this workflow in the centralized repository so it can be reused across various plugin library repositories.

• https://github.com/eslint/markdown/blob/main/.github/workflows/ci-build-all-pm.yml
• https://github.com/eslint/json/blob/main/.github/workflows/ci-build-all-pm.yml
• https://github.com/eslint/css/blob/main/.github/workflows/ci-build-all-pm.yml

6. release-please.yml ⚠️

The release-please.yml workflow is used in various repositories to manage the release process. However, since this workflow can vary depending on the project, I'm not sure if it makes sense to include it here.

Extracting only the common logic—such as posting release information to various social media platforms—might be a better approach.

Used in

• https://github.com/eslint/markdown/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/json/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/css/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/rewrite/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/create-config/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/generator-eslint/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/csstree/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/js/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/config-inspector/blob/main/.github/workflows/release-please.yml
• https://github.com/eslint/eslint-transforms/blob/main/.github/workflows/release-please.yml

7. ci.yml ⚠️

Just like with the release-please.yml workflow, this workflow can vary depending on the project, so I'm not sure if it makes sense to include it here.

However, since we have a package.json convention, I think extracting the common logic related to the package.json convention could be a good approach.

Since most repositories have lint or fmt scripts available, it might make sense to extract and centralize just these scripts here.

Used in

• https://github.com/eslint/eslint.org/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/markdown/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/json/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/css/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/rewrite/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/create-config/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/generator-eslint/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/tsc-meetings/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/js/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/code-explorer/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/eslint-github-bot/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/eslint-transforms/blob/main/.github/workflows/ci.yml
• https://github.com/eslint/eslint-release/blob/main/.github/workflows/ci.yml

8. stale.yml ⚠️

Since we maintain a variety of projects, it's easy to lose track of certain issues or PRs. I sometimes miss notifications, issues, or PRs, which can slow down progress on certain tasks.

Personally, I’d like to see this included in the repositories to help remind authors and teams regularly.

However, I’m not completely sure if it’s worth doing 😄 so I’d like to hear team's thoughts on including this workflow here.

Used in

• https://github.com/eslint/create-config/blob/main/.github/workflows/stale.yml
• https://github.com/eslint/eslint/blob/main/.github/workflows/stale.yml

9. codeql-analysis.yml ✅

CodeQL Analysis is a workflow that helps detect security vulnerabilities.

Since there have been some security issues across ESLint repositories, I think adding this workflow to our repositories would be helpful for identifying security problems in advance.

There are two ways to set up this workflow on GitHub. One is to use an explicit codeql-analysis.yml workflow, and the other is to use the default setup in the GitHub "Settings" tab.

Alternative (Default setup in GitHub "Settings" tab)

We can set up this workflow without an explicit codeql-analysis.yml file by configuring it in the "Settings" tab on GitHub.

For more details, please refer to this guide: https://docs.github.com/en/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning

Used in

• https://github.com/eslint/eslint/blob/main/.github/workflows/codeql-analysis.yml

---

Checklist

I'm using this checklist to make sure all the workflows are set up correctly in the ESLint repository 😄

• ✅: Completed
• 🚧: In progress
• ❌: Not started yet

repository	add-to-triage	stale	renovate	update-readme	bun-test	ci-build-all-pm
.github	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
code-explorer	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
create-config	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
css	✅ (automated)	🚧 (pr)	❌	❌	❌	❌
csstree	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
eslint	✅ (automated)	🚧 (pr)	❌	❌	❌	❌
eslint-github-bot	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
eslint-release	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
eslint-transforms	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
eslint.org	✅ (automated)	🚧 (pr)	❌	❌	❌	❌
eslintrc	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
generator-eslint	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
js	✅ (automated)	🚧 (pr)	❌	❌	❌	❌
json	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
markdown	✅ (pr)	🚧 (pr)	❌	❌	❌	❌
rewrite	✅ (automated)	🚧 (pr)	❌	❌	❌	❌
workflows	✅ (issue, pr)	✅ (pr)	❌	❌	❌	❌
zh-hans.docs.eslint.org	✅ (pr)	🚧 (pr)	❌	❌	❌	❌

[lumirlumir]

I've found 9 useful workflows that are used across ESLint repositories.

I've included brief descriptions and where these workflows are used, so I hope the team and others can share their feedback 😄

This issue is now ready for review. Ping @eslint/eslint-team @eslint/website-team

[nzakas]

Thanks for putting this together. I think this is a good summation. My thoughts:

• renovate.json5 - I think it's good to centralize this, but we need to keep in mind that the main eslint repo has different needs than other repos. It's probably okay to have one config that all repos except eslint can use. I'd also like us to use a less aggressive setting for devDependencies, as it seems like those are the ones that come up most often but also are the least important.
• release-please.yml - I don't see a way we can make this common to all repos.
• ci.yml - Similarly, this tends to be repo-specific and I don't know that it makes sense to try and standardize.
• stale.yml - I think we should do this. It's just too hard to keep track of all the issues and this provides a nice reminder.
• **codeql-analysis.yml` - I'm not sure how useful this actually is. Because ESLint is a CLI tool, it's not really subject to malicious exploits that would affect web servers. The issues last week don't really have any attack vector but they cause a lot of concern.

[lumirlumir]

@nzakas Thanks for the summary 👍

Based on the comments, here’s how I’d prioritize the workflows:

Highest

These workflows can help reduce maintenance costs, so it’d be great to implement them first.

1. add-to-triage.yml
2. stale.yml
3. renovate.json5

Low

These workflows are working well for now and probably won’t change soon. Still, centralizing them could be helpful if there are any updates or when creating a new repository.

1. update-readme.md
2. bun-test.yml
3. ci-build-all-pm.yml

Pending

We can revisit these if there’s more demand in the future.

1. codeql-analysis

---

I’ll start with the highest priority workflows and move on to the low priority ones after that.

[nzakas]

Sounds good. 👍