GitHub actions

[cjgrady]

Here are a bunch of GitHub action related links that seem useful / promising. Many of them are directly linked through the various introduction / learning pages about GitHub actions.

Introduction / overview:

• Introduction to GitHub Actions
• Learn GitHub Actions
• Actions Guides
• Workflow Syntax
• Workflow trigger events

Specifics that we may be interested in:

• Sharing Workflows with Organization
• Building and Testing Python
• Migrating from TravisCI
• Super-Linter Action
• Release Action
• Packaging
• Security
• Continuous Integration
• Spectral for Linting OpenAPI (Included in Super-Linter)

[cjgrady]

As we talked about in our meeting 2021-04-01, we should talk with @benanhalt about his experience since he seems to have done quite a bit with GitHub actions

[benanhalt]

We have actions that build and package Specify 6, and some that run tests on Specify 7 and build Docker images. Happy to talk about it.

[cjgrady]

We are hoping to schedule a time to chat with you about it sometime next week. I'm sure it will come up tomorrow

[maxpatiiuk]

From Super-Linter's README: There is some desire to move this closer to local development for faster feedback on linting errors but this is not yet supported. That is kind of deal breaker for me.

I would rather run the linter before each commit.
A better solution might be to have linter settings in a repository like lifemapper/dotfiles (example) and distribute them to every programmer, who then configures linter to run in a pre-commit hook. This would help catch errors much earlier and remove the need for awkward Fixing linter errors, Making linter satisfied, Fixing a typo commits.

If each developer has a pre-commit hook, I can see super-linter being useful only for catching code style issues in code pushed by outside contributors.

Thoughs?

[cjgrady]

I believe you can run it locally via docker. I agree that it is better to run it before pushing to the repository and a pre-commit hook could be a good way to do that. I'd rather set super-linter up on the repository side to only run for pull requests rather than every push.

[maxpatiiuk]

I found what I was looking for - https://pre-commit.com/

A framework for managing and maintaining multi-language pre-commit hooks.

I was so excited that I spent all day today playing with it.

Here are all the hooks I have it run: https://github.com/maxpatiiuk/dotfiles/blob/main/git/.pre-commit-config.yaml

This is how it looks like when some of them fail:

And here all of them passed:

There is a zillion cool hooks here - https://pre-commit.com/hooks.html
I even wrote some on my own - https://github.com/maxpatiiuk/pre-commit

@cjgrady It can fully replace super-linter. I have flake8 and black setup using these pre-commit hooks

And to put the final nail into super-linter's coffin, you can run pre-hook as a GitHub action! Yeah, I know, this is super cool. More info

@benanhalt I am going to use some of these hooks for all of the new .js and .ts files going forward (along with eslint I am currently using). Though, if you would also want to adopt them for .py files, I would be more than happy to do so.

[cjgrady]

Oh cool, I'll check it out!

[maxpatiiuk]

Here is our config:
https://github.com/specify/specify7/blob/wbplanview-tests/.pre-commit-config.yaml