Less ci computation - Githubissues

NLeSC / python-template

Netherlands eScience Center Python Template

https://research-software-directory.org/software/nlesc-python-template

Apache License 2.0

163 stars 73 forks source link

Less ci computation #345

Open cwmeijer opened 12 months ago

cwmeijer commented 12 months ago

I propose

fewer builds by only running on the first and latest supported python versions (@egpbos ' idea)
only run build jobs on several configurations when a single configuration has succeeded already

Pro:

less computation 🍃

Cons:

More time needed to finish the build job, as most runs will start only after the first has succeeded
We might miss a failing python version sometimes (only in quite special cases I imagine)

I did exactly this change in my own package, created using the python-template (see https://github.com/dianna-ai/distance_explainer/pull/7/files). I propose to do this exact change on the template as well.

LourensVeen commented 12 months ago

Also con: additional complexity and maintenance burden. Not necessarily a show-stopper, but something to think about: how do you implement these things as simply as possible?

egpbos commented 12 months ago

I saw that @cwmeijer was already experimenting with this in https://github.com/dianna-ai/distance_explainer/pull/7/files. Reviewing that commit in this thread (just to display some blatant violation of best practices of basic communication, let alone collaborative development :D), I would say it would be very much preferable if there were still only one job definition and the dependencies could be defined on the matrix-element level within that job... Is that an option? Then maintenance burden would be minimal.

Edit: I see now that Chris already mentioned that PR himself, d'oh. Talk about blatant violations of best practices of basic communication :D

egpbos commented 11 months ago

Note that https://github.com/NLeSC/GREEN/issues/24 lists another bunch of cool ideas. I'm all for implementing these here as well. The maintainability is a concern, so we should document things well (maybe just in inline comments?).

cwmeijer commented 11 months ago

A single job definition would absolutely be favorable. I don't know how to do that though. Suggestions are very welcome.

egpbos commented 8 months ago

To keep things simple, we could also just set fail-fast to true. This will still start running the other matrix jobs, but will kill them as soon as one fails. It's not perfect, in terms of green-ness, but I think a pretty good compromise with maintainability?