Thoughts about the future of Unified CI about .github HOT 3 CLOSED

Thanks for writing this up @galargh . What would be your primary before/after metrics you would look at to gauge the impact of this endeavor?

from .github.

1. Decrease time spent on Unified CI maintenance by IPDX. I'd like to eliminate/minimise the need for our involvement in deploying Unified CI to new repositories and deploying new Unified CI releases. Right now, we reverted to semi-manual handling of both because they became too disruptive at the scale that Unified CI reached.
2. Increase the variety of workflows offered as part of Unified CI. I want it to be easier to introduce new workflows to Unified CI and to opt-in to a subset of optional workflows on the target repository side. With that, I'd like Unified CI to cover a wider range of automation needs. For example, I'd like us to be able to easily cover a variety of release workflows that are used/needed across PL, see pl-strflt/ipdx#82 (comment).
3. Increase development speed in Unified CI. This is kind of a combination of 1. and 2. With less time spent on maintenance and a push for more workflows inside Unified CI, I see development speed in this repository increasing. By this, I mean more undisruptive (only reaching those who are waiting for more frequent releases while not bothering the majority of the repos) Unified CI releases that focus on "features" (new workflows, speedups, UX improvements, etc.).

from .github.

https://github.com/pl-strflt/uci is out! I'm going through the issues now, transferring what's relevant, and I'll archive this repo soon.

from .github.