👷 Add temporary CI for package builds

[PhazonicRidley]

No description provided.

[kammce]

Any reason you didn't just copy the CI files from https://github.com/libhal/async_context/tree/main/.github/workflows ? There should be no difference between this library and what is in async context. Async context and strong_ptr, and all other generic libraries should all use the same workflow dispatches. The workflows there will build for all of the targets we plan to target including the MCUs. This is missing all of the ARM targets.

I'd recommend just copying and pasting that what we have, rather than making a bespoke CI for just this project.

[PhazonicRidley]

Any reason you didn't just copy the CI files from https://github.com/libhal/async_context/tree/main/.github/workflows ? There should be no difference between this library and what is in async context. Async context and strong_ptr, and all other generic libraries should all use the same workflow dispatches. The workflows there will build for all of the targets we plan to target including the MCUs. This is missing all of the ARM targets.

I'd recommend just copying and pasting that what we have, rather than making a bespoke CI for just this project.

Didn't see that. I can use those files however, I do want to make builds for all three major operating systems so I think I will refactor that implementation slightly and PR libhal/ci for the standalone libraries (or make it its own repo/action) this way we don't need to copy-paste things if we decide to update or change things in the future. Most of this ci can be itself a standalone action (setting up conan and preparing it with our profiles).

[kammce]

Any reason you didn't just copy the CI files from https://github.com/libhal/async_context/tree/main/.github/workflows ? There should be no difference between this library and what is in async context. Async context and strong_ptr, and all other generic libraries should all use the same workflow dispatches. The workflows there will build for all of the targets we plan to target including the MCUs. This is missing all of the ARM targets.
I'd recommend just copying and pasting that what we have, rather than making a bespoke CI for just this project.

Didn't see that. I can use those files however, I do want to make builds for all three major operating systems so I think I will refactor that implementation slightly and PR libhal/ci for the standalone libraries (or make it its own repo/action) this way we don't need to copy-paste things if we decide to update or change things in the future. Most of this ci can be itself a standalone action (setting up conan and preparing it with our profiles).

I'm kind of lost. Have you not taken a look at the other CI files to see what they do? If you have, ehat makes you think that the CI workflows within async context and strong ptr do not get built for all major OSes. We not only support the major OSes but also each MCU architecture. I'm asking you to re-use those files because they directly use the global workflows in libhal/CI which support each OS/arch and each MCU. We may skip Windows for now, but that can be added in to the proper CI workflow withi the CI repo. Adding in a bespoke workflow for each repo is a major maintenance burden that we should only afford ourselves when it's absolutely necessary. For example libhal-arm-MCU, doesn't use the generic CI package and deploy because it doesn't need to build the binaries for anything other than the arm MCUs.

The files within async context and strong ptr use the generic https://github.com/libhal/ci/blob/main/.github/workflows/package_and_upload_all.yml which builds for everything we current have full support for.

Also, you are missing the arm versions of the OSes.

[kammce]

Some of my comments will become irrelevant once you replace these contents with the workflows with libhal/CI.

[kammce]

Do not use main, use 5.x.y if you want the latest without breaking changes.

[kammce]

Every TODO needs an issue number. We must have some sort of non-code tracking for these.

[kammce]

You are missing the arm architectures as well.

[kammce]

Why add this dependency when we could also just use pipx install conan? Its the same number of lines but then we just have to worry about pipx for Conan working and not yet another github action which may, at some point stop getting updates. If that happens, which has happened to me in the past, it's a maintenance burden to update all of that. Especially if each repo is getting its own action.

[PhazonicRidley]

As discussed, for now this package will use the ci that the other standalone libraries use and I will pr my CI ideas in a generic sense.. I will leave the comments relating to ci unresolved so I can reference them later when designing new CI ideas for the libhal ecosystem.