Is your feature request related to a problem? Please describe.
The BPLib test workflows utilize actions, scripts, and other software that come from other NASA repositories as well as as some 3rd parties (e.g. NASA OSAL, cppcheck, tinycbor, etc). As the upstream projects release new versions, sometimes this can cause changes to a workflow behavior even though the BPLib source code is not changed at all.
Describe the solution you'd like
In addition to running workflows with every BPLib change, they should be run once a week as a scheduled run even if nothing is changed in BPLib, to confirm that all the dependent items are still working as expected, in case something changed outside the control of BPLib.
Describe alternatives you've considered
Keep as is, but this has been an issue with other projects in that a change caused by an external factor is only noticed after a real code change, and things get confusing. Plus, this can cause long delays between when a breakage occurs and when it is noticed/addressed.
Additional context
While this is most relevant to libraries that don't change very often, its still a good idea IMO.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
Is your feature request related to a problem? Please describe.
The BPLib test workflows utilize actions, scripts, and other software that come from other NASA repositories as well as as some 3rd parties (e.g. NASA OSAL, cppcheck, tinycbor, etc). As the upstream projects release new versions, sometimes this can cause changes to a workflow behavior even though the BPLib source code is not changed at all.
Describe the solution you'd like
In addition to running workflows with every BPLib change, they should be run once a week as a scheduled run even if nothing is changed in BPLib, to confirm that all the dependent items are still working as expected, in case something changed outside the control of BPLib.
Describe alternatives you've considered
Keep as is, but this has been an issue with other projects in that a change caused by an external factor is only noticed after a real code change, and things get confusing. Plus, this can cause long delays between when a breakage occurs and when it is noticed/addressed.
Additional context
While this is most relevant to libraries that don't change very often, its still a good idea IMO.
Requester Info
Joseph Hickey, Vantage Systems, Inc.