I audit here. Auditing via Github Actions makes sense if you work in a team and want to make sure that everyone adheres to a style/system. If I am working as single entity on something I can run my audit before I commit or push or even while running the server.
Thank you for reminding of that option. I hadn’t considered that as ‘a thing’. Quite a while ago I felt that way, but have since changed my mind. Without getting into an off-topic discussion on when and when not to CI and automation, all I’ll say is that I don’t trust myself enough to run the necessary scripting (or worse, for me, multiple manual steps) when I’m impatient or distracted, so I automate. That way I’m less likely to omit the testing (and during a recent update to my tech website I was reminded that when I skip steps, I mess things up, because I deployed without pushing and triggering CI and I did it wrong). So, for myself, the CI and GA is necessary. YMMV.
automate checks before git actions (hooks): check out pre-commit. Think of private API keys in your repo and finding them before they go “live” on GitHub. Or simple linting. I put everything (even some unneccessary stuff) into my config, but it catches a lot of potential issues early on. I think I even started a Hugo related check (the ones by jmooring) somewhere but didn’t get around to fix it up (mostly because the wait for hugo to run is too much for a simple commit. I guess that check is better in a local server script. I am using --renderToDisk to have these files available and then run it on the local server.
Long story short: yeah, Github CI is great, but not only do they have a limited number of minutes available for free, you can also quite fast slide down the rabbit hole of “too much”.
Thank you for that! I knew about git hooks, but this makes using them much, much more doable. I think I’ll move my markdown linting in there (it’s quick enough and I only need to make a few changes to my lint config to use one of the available hooks) as well.
Hope you don’t mind if a ‘borrow’ (with acknowledgement) and tweak a few of your configs for use with pre-commit . The audit I think is too heavy for a pre-commit hook. I appreciate what you say about the limited number of minutes (I’ve toyed with setting up something like SourceHut or a local GitLab instance, but the amount of time spent vs. buying a GitHub ‘Pro’ plan is quite an investment). The other thing, though, is that I have hopes (delusions)? that I will get collaborators on some of the repositories, so that I’ll want the proper CI in place.
Anyway, pre-commit is cool, but the markdown linting is the only thing I think it’s appropriate for that I’m currently doing with GHA, but that’s my opinion and mine alone, and all that malarkey.
I’m probably going to have change my process anyway because the GHA pipelines are taking a long time because of the way you have to communicate between jobs. I have a ticket open with GH, but if there is no resolution, I’ll have to do something else. Ah, well, if you don’t try, you don’t know.
. The audit I think is too heavy for a pre-commit hook. I appreciate what you say about the limited number of minutes (I’ve toyed with setting up something like