Missing syntax highlighting for some code snippets

[surajyadav1108]

this is just a slight docs enhancement as on the docs there are some code-snipets like YAML example without proper syntax-highlighting we can add that easily in there

[cwilkers]

Thanks for bringing this up, there are about three responses I can think of to help with this:

1. I would invite you to create PRs to add in the syntax highlighting where it needs to be. Most of these will be identifying the type of code and adding the appropriate annotation to the code block to tell Jekyll what it is.
2. If you have seen more than a few, it would be helpful to create a list of the pages with un-highlighted code blocks.
3. If you have experience with CI/CD, it would be helpful to add a check to our PRs in kubevirt/project-infra that would lint the markdown, and catch these issues during review.

[surajyadav1108]

@cwilkers Sorry for the late response. have been catching up on some things. went through the docs and there were a lot of pages so instead of making a list I decided to change it myself and added the yaml tags for code blocks wherever I felt it was fitting and replaced the console tag with yaml in some places .

As for CI/CD I do have experience with it but I have mostly worked with github actions, Jenkins etc. but found out prow is being utilised here, and I'm not familier with it as of now. So looked for some info about it, and I did understand the structure of jobs in Prow, for example, looking through the kubevirt/project-infra

I belive the user-guide-presubmits.yaml is the file for PR integration checks on for user-guide repo. I could be wrong, but I am still not sure how to work with the images used inside the conatiner

image: quay.io/kubevirtci/kubevirt-kubevirt.github.io:v20220825-9d7149f

is it required to use this image for the job cause it doesn't have npm to install markdownlint in it or do we need to modify this on the repo itself?

presubmits: kubevirt/user-guide:

• name: check-links-user-guide always_run: false skip_report: true decorate: true cluster: kubevirt-prow-control-plane spec: containers:
  • image: quay.io/kubevirtci/kubevirt-kubevirt.github.io:v20220825-9d7149f command: [ "/usr/bin/bash", "-c" ] args:
    • "rake -- -u"

[cwilkers]

A good way to test the container we're using in CI is to explore the Makefile in this repo. You can build and test locally, updating the dockerfile as you require, then we can talk about how to get that pushed to the project-infra repo. In essence, the Dockerfile you will start with is copied from that repo anyway.

[surajyadav1108]

A good way to test the container we're using in CI is to explore the Makefile in this repo. You can build and test locally, updating the dockerfile as you require, then we can talk about how to get that pushed to the project-infra repo. In essence, the Dockerfile you will start with is copied from that repo anyway.

I have tested the image present in the presubmit job image: quay.io/kubevirtci/kubevirt-kubevirt.github.io:v20220825-9d7149f locally and it can perform the markdown linting just fine, So I think there is no need change anything in the Dockerfile

docker run -v "$(pwd):/workspace" -w /workspace quay.io/kubevirtci/kubevirt-kubevirt.github.io:v20220825-9d7149f markdownlint .

Now as for the presubmit job this is what I am currently thinking to use

 - name: markdownlint-user-guide
    run_if_changed: '\.md$'
    always_run: false
    skip_report: false
    decorate: true
    cluster: kubevirt-prow-control-plane
    spec:
      containers:
      - name: markdownlint-container
        image: quay.io/kubevirtci/kubevirt-kubevirt.github.io:v20220825-9d7149f
        command: [ "/usr/bin/bash", "-c" ]
        args:
        - "markdownlint ."

Also it would be better to add a lint-fix script command in the Makefile so if someone new make some changes in docs and get a test-failure can fix it on their local clone before pushing it, as linters could be annoying for new contributors.

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[kubevirt-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

[kubevirt-bot]

@kubevirt-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.