Setting up GitHub Action for CSS and future linting

[averdin2]

Fixes #1441

What changes did you make and why did you make them?

• I created a new file in .github/workflows called linter.yml, to make a new GitHub action for the website repo to act as a code linter.
• This specific issue is dealing with setting up CSS linting for our repo, but this same GitHub action can be used for JavaScript linting as well.
• I also added a stylelintrc.json file in the root of the project which is a configuration file for the CSS linting rules we want the GitHub action to run.
• Here is a link to a pull request I made on my forked repo showing the linting message for an example of what the messages will look like: https://github.com/averdin2/website/pull/1/checks?check_run_id=3032527940

Resources Used

• The specific resource I used for the GitHub action is called SuperLinter. It is an official GitHub action for linting code made by Github themselves.
• A list of the stylelint rules (including the ones in the .stylelintrc.json file) can be found here.

Review Steps

1. Run the GitHub action on your own repo. To do so, you will need to make a pull request with changes to a SCSS file. You will also need to change the specified branch that the GitHub action checks in the linter.yml file on lines 5 and 23 to the branch you are making the test pull request. I recommend making an intentional linting error. The easiest way to do this is to make a duplicate class, but you can also test out one of the other errors (See .stylelintrc file for rules implemented, and here for list of rules and what they do).
2. Intentionally cause a linting failure from the GitHub action on a Pull Request. Then, fix the changes and commit and push your changes to the PR's branch. See if the GitHub action updates to show no errors.
3. Now, make another error and check if the GitHub action catches the errors (try this with a different file than step 2).
4. If everything works well, repeat the above steps, but on the website repo.

Notes

• In the linter.yml file, on line 22 the VALIDATE_ALL_CODEBASE: false means that the GitHub action only checks committed files to the repo. The reason why I am not checking the entire codebase is that I do not believe it is necessary to run a check on the entire codebase for every pull request. I made issue Make Style Linting Fixes #1958 to deal with all the errors that are in the current codebase as a result of running VALIDATE_ALL_CODEBASE: true. I believe after fixing these issues, only checking the files in new pull requests should be sufficient for linting the codebase.
• The types of rules I implemented are only those whose failure would likely result in actual style errors like not enacting the proper styles. I did not add any rules that limit features or require more strict enforcement of particular code formatting rules. If linting rules like these wanted to be added in the future, we can do this by adding rules to the .stylelintrc.json file.
• To add linting for another language (like JavaScript), we can use the same GitHub action to do so. (See here)

[averdin2]

I made this pull request a draft because I ran into some potential linting annoyances when working on issue #1958. I want to see if I can configure some of the style rules to stop the problem I ran into before merging.

[GLRJr]

@averdin2 will make review steps

[Aveline-art]

@averdin2 Can we schedule a time to do a demo either on a Tuesday or Thursday meeting?

[averdin2]

@averdin2 Add on push back into linter config file.

[Aveline-art]

@averdin2 From testing, I had found that the linting config files needs to be in both the incoming branch and the merge into branch. Without the files existing in both, I get this error:

Error: ENOENT: no such file or directory, open '/github/workspace/github/workspace/.stylelintrc.json'

Can you confirm that this is the case?

Also, the output from the linter is very useful, so I am wondering if the linter module provides a way of gathering or caching the data into a variable(preferred) or an artifact(less preferred)? That way, we can output it as a comment. If not, we might need a follow-up issue to add documentation on resolving linting issues.

[Aveline-art]

Just one small architectural change. Everything else is awesome!

[macho-catt]

Awesome work on this Alex! Just an additional thing after the backend meeting yesterday, we decided on a new structure for our Github actions. Click here for google sheet.

Basically linters will be on their own files (so SCSS linting will be on its own, JS linting on its own, etc.)

To reflect that change, could you edit the name of this action to something like "Lint SCSS" and rename the yml file to something like "lint-scss.yml"? Could you also update any other names in the workflow to reflect that?

Other than that, good job again on this.

[abuna1985]

@Aveline-art will contact @averdin2 regarding the changes for pull request. @Aveline-art will complete the changes if needed.

[macho-catt]

I tested this once more in my environment, and it looks good to me. I do agree with @Aveline-art about finding a way to logging the outputs into a comment, or writing a doc on how to resolve linting errors. However, I think that is something we can open as a new issue.

We discussed this part during the Tues meeting