ci: Adding workflow_call to make a consistent ecosystem for FIREWHEEL

[sdelliot]

No description provided.

[sdelliot]

@mitchnegus do you have thoughts on how to effectively test this without lots of merges?

[mitchnegus]

@mitchnegus do you have thoughts on how to effectively test this without lots of merges?

I think we could make a branch here on the main repo (not your fork) and then reference that branch in the MC workflows.

There are some other factors that may cause it not to work so well for the PR title checker (does that use the target branch's workflow or the repo's default workflow? I'm not sure). Same thing for the release drafter, but that might work better if we release a development/alpha release.

[mitchnegus]

@sdelliot Give that PR (sandialabs/firewheel_repo_linux#5) a look. The CI there uses this branch to check the PR title successfully.

We would still need to change that to point at the FIREWHEEL main branch (or a specific version), rather than the ci-consistent-ecosystem branch, but at least this shows the link to the reusable workflow here working properly.

Also, the release drafter will require that a configuration file exist in the .github directory. From the documentation, that seems non-negotiable ("no other configurations will be accepted"), so unfortunately I don't see a way to point it to the config in this repo instead.

[mitchnegus]

Also, I noticed that we have some workflows with the .yaml suffix and some with the .yml suffix. My brain doesn't like the inconsistency and I foresee that at some point down the line someone might write a workflow reference a .yml when they should have referenced a .yaml and find that irksome.

It's probably easier to make standard now than later once we start putting these references in more repos, but I'll leave it to you to decide if it's worth it. I haven't looked to see where we use one suffix or the other, so I honestly don't know if this is already going to be a pain to standardize.