search

IRNAS / irnas-guidelines-docs

This repository contains guidelines related to various aspects of managing GitHub repositories at IRNAS and working with them.
Other
2 stars 1 forks source link

Add "provisioning" repo_type specifier #30

Open NejcKle opened 1 year ago

NejcKle commented 1 year ago

Many of the projects at IRNAS require some kind of a provisioning step. Often times the provisioning process requires multiple steps, such as hardware testing, lr1110 provisioning, nrf52/nrf91 configuration, etc.

We have created a new internal testing/provisioning library for the ZPT1200, which provides method to interface with the functionality. The irnas-provisioning-software can be found here.

As more projects start to make use of the above mentioned library, me and @SloMusti think it would make sense to create a new provisioning repo_type specifier. The specifier should get used in projects where the provisioning process is more complex than a few lines of bash scripts, current examples being the smartparks-provisioning-software and telespor-provisioning-software.

For example, using the new repo_type specifier the telespor-provisioning-software would get renamed to telespor-tracker_3-provisioning.

Please share your thoughts on this matter.

MarkoSagadin commented 1 year ago

Thank you for an opening an issue and providing a relevant reasoning :+1:

I agree with the addition of a new repo_type specifier. Please open a PR with added specifier, add a short description what what kind of projects should use provisioning specifier. When that PR is merged this issue can be closed.

As a side note: I personally feel that is better that both provisioning/test code and a firmware code, that is tested, are located in the same repo. I think it is easier to ensure that there is no mismatch between the state of the firmware and the state of the provision code that tests it. When a release of a such project is made then you can easily indicate if the current state of firmware passed the provisioning (CI check, mandatory manual check at release, etc.).

With two repos you have to be extra diligent about making sure that there is no mismatch. Thinking from this point: how hard is it for somebody to pick up a 4 months old project and validate it that it works?

To be clear, both approaches can work, I just think that the "same repo" is easier to maintain.