Feature: green software practices

[jwallwork23]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through both the open and closed issues for a duplicate request.

What's the problem this feature will solve?

Thanks for developing zizmor - I've found it to be a really useful tool and am making use of it in various projects.

I've been thinking about green software engineering practices and have recently been looking into green CI, i.e., reducing resource wastage in CI workflows. Some colleagues and I created https://github.com/Cambridge-ICCS/green-ci during a hackathon and it documents some of the things I mean.

Describe the solution you'd like

It'd be great to add some such rules to zizmor to encourage green CI usage. What I propose:

• 1. Always include a timeout on jobs to avoid wasted resources when jobs stall (should be fixed by Feature: Require or recommend the timeout-minutes property for all jobs #1023 #1067).
• 2. Always set up a concurrency check that cancels running workflows when they get re-triggered (you don't need the original jobs to finish if you've already updated the branch).
• 3. Use a separation of concerns approach to separate out workflows (tests, static analysis, docs) and only trigger each when associated files change.

If you agree that 2 sounds like a good idea then I'd be happy to take it on. I've been learning Rust this week and it'd be a great way to practice.

With 3 it wouldn't apply in all cases and doesn't seem like a good fit for a hard rule, but it might be nice to have a warning or info message to encourage this?

Additional context

No response

[woodruffw]

Hi @jwallwork23, thanks for opening this issue!

I'll respond to each of your specific ideas below (all of which sound good to me), but as a more categorical response first: the goal with zizmor is primarily security audits, not general code quality or other IMO worthwhile checks. If you're looking to write checks that don't have a security angle for the GitHub Actions ecosystem, I would definitely recommend checking out actionlint -- they do a much larger set of CQA checks than zizmor intends to 🙂

With that said, I do think there's a strong argument to be made that "resource waste" vectors can be a security risk, so that's not a categorical rejection! It's just something I wanted to broadcast as a deciding factor for whether I'm likely to accept an audit.

Now, for the specific ideas:

Always include a timeout on jobs to avoid wasted resources when jobs stall (should be fixed by Feature: Require or recommend the timeout-minutes property for all jobs #1023 #1067).

Yes, this would be a great audit to have! If you're interesting in contributing it, that would be fantastic.

(I think this would need to be a pedantic-level audit initially, since the actual timeout a job should use is context sensitive.)

Always set up a concurrency check that cancels running workflows when they get re-triggered (you don't need the original jobs to finish if you've already updated the branch).

Same as above -- I think this would be great if you want to contribute it. This one could probably be non-pedantic.

Use a separation of concerns approach to separate out workflows (tests, static analysis, docs) and only trigger each when associated files change.

I think it would be great to be able to check this, but I don't have a clear sense of how zizmor would do so reliably: those concerns are mostly conventional and so are repository layouts, so it's hard to statically assert which set of files should trigger which concern. But I'm curious if you have thoughts there.

but it might be nice to have a warning or info message to encourage this?

Yep, this is what the "pedantic" finding persona is for:

https://docs.zizmor.sh/usage/#using-personas

[jwallwork23]

Thanks for the detailed response!

For the timeout one, I'll leave it to @EmmanuelBerkowicz who wrote #1067 because they seem to be most of the way there.

Great - I'll take a look at the concurrency one and get back to you if and when I have a PR.

On the separation of concerns/triggers one, I agree that it'd be difficult to implement. In the repos I work on I usually have

• test workflow triggers if source file types, build system, dependencies, or the workflow itself change
• linting workflow only triggers when corresponding source file types or the workflow itself change
• docs workflow only triggers when docs file types or the workflow itself change (although depends if there are API docs)

etc. I guess a starting point would be to encourage the use of path triggers and to have more than one workflow, but this wouldn't work for every situation.