Shared actions 🔥

[emphasize]

No more fumbling around on a per repo basis.

[mikejgray]

Great additions! I have some recommendations to help future-proof these a bit

[mikejgray]

Outstanding work! A couple of questions as I'm not sure how the edge cases would be handled, but otherwise LGTM

[builderjer]

If these are to be common usage, and required additions to an "official package" skill or otherwise, I think a good README.md of how to use these would be justified.

[emphasize]

What's the deal with the existing README text anyway? Doesn't really fit in

[j1nx]

What's the deal with the existing README text anyway? Doesn't really fit in

Feel free to adjust to what fits in. I believe that was once just cooy/pasted it when the repo got created.

[goldyfruit]

Awesome 👍 Good job @emphasize!

[mikejgray]

Small nit, but nothing that would hold up an approval. Nicely done!

[NeonDaniel]

I haven't been able to test all of the automations, but left notes where test cases may be importable from neon-minerva to consolidate things/prevent diverging changes

[NeonDaniel]

This appears to be a functionally equivalent to neon-minerva. consider install/import to reduce duplicated code

[NeonDaniel]

Direct copy of neon-minerva test class, consider installing/importing rather than duplicating for future maintenance

[JarbasAl]

importable from neon-minerva to consolidate things/prevent diverging changes

this would make us unable to test anything pinning a higher version that minerva allows, in general it is expected that minerva will be slower to adopt anything we do in ovos due to Neon being downstream, shouldnt be an issue right now, but i think it will be an issue sooner or later, its one major ovos-utils or ovos-workshop update away

I also expect the code to diverge, as a lot of minerva will be Neon specific and not apply to us necessarily, or make assumptions that only apply to Neon, scope of the package will be very different even if some tests are shared

This isnt really a problem now, but something to consider, i prefer to have any essential infra under the OVOS org if all ovos packages are going to literally depend on this

We can ofc change things at any point if incompatibilities arise, so this isnt necessarily a blocker if everyone else thinks it best to import minerva, i feel we are better future proofed this way but dont particularly care either way right now

[JarbasAl]

let's get this one merged and follow up with companion tweaks in separate PRs as needed :)

this is awesome work by @emphasize , a bunch of our repos have no automations, we can start by testing the new stuff live on those right away to iron out any quirks in the process

[NeonDaniel]

let's get this one merged and follow up with companion tweaks in separate PRs as needed :)

this is awesome work by @emphasize , a bunch of our repos have no automations, we can start by testing the new stuff live on those right away to iron out any quirks in the process

We should have at least some validation of every added automation; I would suggest we break this up into smaller PRs so we can validate one or a few things at a time.

I'll also note that some of these appear to be duplicates from https://github.com/NeonGeckoCom/.github/tree/master/.github/workflows which are already in use in OVOS projects and it would be less work to contrib changes there than updating all of the existing workflows

[NeonDaniel]

importable from neon-minerva to consolidate things/prevent diverging changes

this would make us unable to test anything pinning a higher version that minerva allows, in general it is expected that minerva will be slower to adopt anything we do in ovos due to Neon being downstream, shouldnt be an issue right now, but i think it will be an issue sooner or later, its one major ovos-utils or ovos-workshop update away

I also expect the code to diverge, as a lot of minerva will be Neon specific and not apply to us necessarily, or make assumptions that only apply to Neon, scope of the package will be very different even if some tests are shared

This isnt really a problem now, but something to consider, i prefer to have any essential infra under the OVOS org if all ovos packages are going to literally depend on this

We can ofc change things at any point if incompatibilities arise, so this isnt necessarily a blocker if everyone else thinks it best to import minerva, i feel we are better future proofed this way but dont particularly care either way right now

Neon has always made an effort to support OVOS skills/plugins explicitly and I'm currently working on adopting the base classes from ovos-workshop directly. ovos-utils in this recent case just needed testing to make sure any breaking changes were accounted for and the dependencies updated; it would be the same work to update the dependencies in this project when a breaking change is pushed.

I'm not going to argue that these have to use minerva, but it would reduce a decent amount of duplicated code and consolidate efforts. Keeping it in minerva also allows use outside of GHA since minerva exposes a CLI for running tests locally.

[mikejgray]

This is a good foundation to start from but still needs a bit of work to get it ready for release, IMHO. Would recommend either prioritizing that effort or closing this PR.