Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Markdownlint job #54

Open
5 tasks
nschonni opened this issue Oct 3, 2022 · 3 comments
Open
5 tasks

Create Markdownlint job #54

nschonni opened this issue Oct 3, 2022 · 3 comments

Comments

@nschonni
Copy link
Contributor

nschonni commented Oct 3, 2022

Could take the basic format as currently done in dotnet/docs#31543 and replace the few repos that have copies of this similar files.

/cc @BillWagner I think this is the repo that I was thinking would be dotnet/workflows

@BillWagner
Copy link
Member

Adding @IEvangelist @gewarren for their thoughts.

@IEvangelist
Copy link
Member

Oh, yeah. I like that! I think it makes sense to take that approach, but I'm struggling to find the immediate benefit to doing this. This idea is to push us more towards using this repo as the source for custom GitHub Actions and compositions of composite GitHub Actions, right? What are the direct benefits to this — would the .markdownlint-cli2.jsonc config file be overridable in consuming repositories, or are you thinking it lives in this repository?

@nschonni
Copy link
Contributor Author

nschonni commented Oct 4, 2022

I think the .markdownlint-cli2.jsonc would still live in the repos, so that it can be consumed by VSCode through the markdownlint plugin (it's bundled in the Docs Authoring Pack AFAIK).

The main benefit of the job being here is mostly in centralizing the problem matcher and keeping the actions/* dependencies up-to-date in one place. You could potentially control the version of the CLI as an optional config vs the current approach of installing the latest on each run.

An alternate config is having package.json and pinned versions in the repos, but common script packages like mdn/workflows#81. That probably doesn't make sense in this org, unless that's a path you want to take.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants