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

Consider Adding a Mark Down Linter GitHub Action #19

Closed
Xtigyro opened this issue Aug 19, 2020 · 6 comments
Closed

Consider Adding a Mark Down Linter GitHub Action #19

Xtigyro opened this issue Aug 19, 2020 · 6 comments

Comments

@Xtigyro
Copy link
Member

Xtigyro commented Aug 19, 2020

As a follow-up of our discussion (me and @scottrigby) - it should be beneficial to add a GitHub Action that does Mark Down linting.

@scottrigby
Copy link
Member

Cool idea. Someone may want to play with these in a PR: https://github.com/marketplace?type=actions&query=markdownlint I would recommend a separate GitHub Actions workflow for this.

@torstenwalter
Copy link
Member

Would be nice if one could execute the same linter locally. I personally like https://pre-commit.com/ as it allows to lint only modified files.

@scottrigby
Copy link
Member

Sounds like someone wants to write a GH Action 😉 (I can relate! They're super-fun)

One note: @Xtigyro mentioned the markdownlint vscode plugin for local work: https://github.com/DavidAnson/vscode-markdownlint (can also be run apart from vscode https://github.com/DavidAnson/markdownlint).

@torstenwalter
Copy link
Member

I added two draft PRs to demonstrate two different approaches. One is using pre-commit and the other one super-linter.

No matter for which we decide we should fix lint errors on all files to improve contributor experience. For example super-linter just checks modified files, which is the reason why everything is ok. It would be bad if we force the first contributor modifying a file to fix all linting errors.

PS: Sorry for the not so well created PRs. It's just terrible trying to author something on a mobile :-)

@scottrigby
Copy link
Member

I agree pre-commit hook approach has the downside of burdening each new user with every previous problem. I find that better for internal teams than projects where we want to encourage many contributors.

superlinter looks pretty cool! Calls https://github.com/igorshubovych/markdownlint-cli#readme which calls https://github.com/DavidAnson/markdownlint anyway… nice 😄 I leave it to the maintainers to decide, but I see nothing wrong in this approach personally from a charts repo CI perspective.

@Xtigyro
Copy link
Member Author

Xtigyro commented Aug 24, 2020

Yeah - I think that's fine. I like superlinter!
I'm also not in favour of pre-commit hooks - my arguments are exactly the same as stated by @scottrigby above.

hectorj2f pushed a commit to hectorj2f/helm-charts that referenced this issue Nov 10, 2021
* update install instructions

Signed-off-by: Jackline Mutua <jmutua@vmware.com>

* fix typo on cosigned readme

Signed-off-by: Jackline Mutua <jmutua@vmware.com>

* update signed example case

Signed-off-by: Jackline Mutua <jmutua@vmware.com>

* update chart version

Signed-off-by: Jackline Mutua <jmutua@vmware.com>

* update chart version

Signed-off-by: Jackline Mutua <jmutua@vmware.com>

* update chart version

Signed-off-by: Jackline Mutua <jmutua@vmware.com>
sathieu pushed a commit to sathieu/helm-charts-prometheus-community that referenced this issue Nov 26, 2021
junotx pushed a commit to junotx/prometheus-helm-charts that referenced this issue Oct 12, 2023
[kube-prometheus-stack] add ks-prometheus project and sync recording rules.
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