Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Action runner cleanup #3
This ties up the rest of the loose ends with the big ol' Action Runner refactor.
Taking a quick look, this makes a lot of sense to me - great work, Alex. The RunOnceHandler test is a lot better and the generic actions are nicely decoupled from RunOnces. The LazyActionRunner is a cool idea and I think it helps solve the decoupling problem (RunOnce vs ContainerHandle) at the right abstraction level.
We have lots of mini-packages now and I'm wondering if we can organize things a bit more to make the top-level a little tighter (this can wait till Monday obviously). Some thoughts:
Just some seed-thoughts for discussion. I'm primarily concerned with test speed (lots of packages = lots of compiling = slightly slower suite) and with grokability (which is subjective and might just be me). Also, I can't decide if the one package = one object rule is a go pattern or a go antipattern and I think logically grouping related things (like actions) into one package makes a lot of sense (again, to me at least...)
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
thanks; fyi I expect this to be something dealt with monday, not a trivial PR like the other bash scripting one was :)
two conflicting thoughts:
Given that most of the packages I've made are probably from the latter tendency it's probably worth circling back and seeing if the practical benefits are worth compromising the former thought, and/or if they make sense organized differently anyway. Some of the remaining packages ended up being just functions (like