Although the submission process is completely automated, other requests (e.g., library repository URL update) are still
handled manually due to requiring additional operations on the backend
The changes to the data files stored in this repository must be coordinated with the associated changes to the Library
Manager database and/or storage systems.
The dedicated "status: pending backend" repository label will be added to the issues and PRs which can be resolved only
after those external operations have been completed; in this manner indicating their status in a clear and machine
readable manner.
The `carlosperate/download-file-action` action is used by GitHub Actions workflows as a convenient way to download
external resources.
A major version ref has been added to that repository. It will always point to the latest release of the "1" major
version series. This means it is no longer necessary to do a full pin of the action version in use as before.
Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from
ongoing development to the action up until such time as a new major release of an action is made. At that time we would
need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major
release before manually updating the major ref (e.g., uses: `carlosperate/download-file-action@v2`). I think this
approach strikes the right balance between stability and maintainability for these workflows.
In order to prevent confusing feedback from the bot, parallel runs of the "Manage PRs" workflow for a given PR are
prevented by canceling any in progress runs for that PR whenever it is triggered.
However, sometimes a trigger event does not result in a run. For example, the workflow is triggered by every comment on
the PR thread, but only those containing the text "ArduinoBot" result in a run. With the previous workflow configuration,
this meant that if anyone made an incidental comment on the PR during a workflow run, the true run was canceled by the
otherwise ignored trigger event, causing a loss of automation.
The solution is to adjust the concurrency configuration so that prior runs in progress are canceled only if the current
trigger event will result in a true run.
I did not indent the added expression because doing so caused validation against the community developed GitHub Actions
workflow JSON schema from the JSON Schema Store to fail.
The reason is that lines with leading whitespace are not folded:
https://yaml.org/spec/1.2.2/#block-folding
Even though the resulting newlines in the expression don't cause any problems for GitHub Actions, the JSON Schema does
not have support for them. Since there is no explicit specification in the GitHub Actions documentation that newlines in
expressions are supported, I am hesitant to propose the necessary change to the schema.
From the library repo https://github.com/Azure/azure-sdk-for-c-arduino.
This new library maps to the new Azure SDK for C that is designed for
embedded development, published on
https://github.com/azure/azure-sdk-for-c.
This new azure-sdk-for-c-arduino library shall be prefered over the previous azure-iot-arduino
library and dependencies (azure-iot-arduino-utility,
azure-iot-arduino-protocol-http, azure-iot-arduino-protocol-mqtt,
azure-iot-arduino-socket-esp32-wifi).
For questions, please refer to maintainer of library.
