This library is being removed from Library Manager by Arduino due to security concerns.
Although there are no concerns about the library code itself, the library.properties metadata file contains an unfortunate typo in the `url` field. This causes the "More Info" link provided by the Library Manager to take the user to a misspelling of github.com owned by a typo squatter. The library author has already corrected this error, but there has not been a release of the library in the ~4 years since that time, and no response to an inquiry about the situation made ~3.5 years ago.
This was surely an honest mistake, without any malicious intent on the library author's part, but we need to resolve the situation. We will be happy to add the library back once the library maintainer has done the following:
- Create a new release or tag in the library's repository with the corrected `url` value.
- Delete the `1.0` tag that has the bad URL from the library's repository.
Add Bluepad32 library for Arduino to registry.
This library adds Bluetooth gamepad support for Arduino boards.
The boards must have a NINA co-processor.
When possible, if problems are detected in a pull request, the bot will attempt to guide the PR author through the
process of making a valid submission, which should be handled in a completely automated fashion on our end.
It has become clear that we need to prevent the removal of the final newline from `repositories.txt`. The existing system
did not accomodate this requirement. Submissions are validated on a per-library basis, and the bot comments based on
identifying which library the problem applies to. But this newline removal is not necessarily related to any specific
item added to the list. So handling for general problems with a submission PR is needed, which is added here.
Because the PR author is more likely to require assistance with resolving this sort of problem, PR review from a
maintainer is requested.
The workflow result might indicate either that the PR author could require assistance from a maintainer or that something
is wrong with the system. In this case, the situation is brought to the attention of the maintainers by requesting a pull
request review from them.
Due to the need to avoid requesting review from a maintainer when they are the PR author (which is not allowed and thus
would result in a spurious workflow failure), the code for requesting this review is not as trivial as might be expected.
Previously, this code was duplicated at multiple places in the workflow, and would become more so as additional code is
added. The workflow is made cleaner by moving that duplicated code to a single dedicated job, which is facilitated by the
recent reworking of the workflow structure.
This is a pure refactoring and should have no effect on the workflow behavior.
Whenever the bot needs to communicate to the user about a blocking issue with their pull request that they are able to
resolve, a standardized prefix is added to the situation-specific error message ("❌ **ERROR:**") to draw their
attention to this information. This standardized text occurred multiple times in the workflow, which might lead to it
becoming inconsistent over time, or just more work to improve the text. Use of an environment variable ensures that all
uses of the prefix will be consistent and allows it to be edited once in a single place.
A new release of `arduino/library-registry-submission-parser` is out with some minor improvements to the error messages
the bot comments to a pull request when problems with a submission are found.
In the event the checks on a submission PR fails, the bot comments with instructions for how the checks can be triggered
to run again once the user has resolved the issue. One option is to comment on the PR thread, mentioning ArduinoBot.
GitHub automatically linkifies mentions to the user's profile page, which occurs in these instructions. The ArduinoBot
profile page is not of relevance or interest in this context, so there is no benefit to providing a one click path for
its access. In addition, the link makes the text more difficult to copy. So it's better to prevent its linkification,
which is achieved by wrapping the text in backticks.
In the event the cause of a submission check failure is resolved externally, the user can trigger the "Manage PRs"
workflow run by mentioning ArduinoBot in a reply to the PR thread. Unlike a workflow run triggered by a push to the pull
request, GitHub Actions does not provide any visible indication on the PR page of the workflow run in progress. Instead,
we have configured the workflow so that the bot immediately comments on the PR thread so that the user is not left
wondering whether their comment had any effect as the longer process of the submission checks finishes before the
feedback about their result can be provided.
With the idea that some users might like to get a progress indicator in the time between the initial comment and the
final feedback from the workflow run, I added a link to the workflow runs page. However, we received feedback from
testers that encountering the fairly cryptic workflow run logs causes confusion. So we are trying to avoid leading users
toward those logs. Since the link does just that and is not necessary, it's best to simply remove it.
The "Manage PRs" GitHub Actions workflow processes pull requests submitted to the repository. It is intended to allow
completely automated submissions of libraries. The feedback mechanism used by the system is comments on the pull request
thread. These comments should provide all the necessary feedback about the process, including whatever is needed to
bring a submission into compliance in the event the automated checks find it to not meet the requirements.
From feedback provided by testers, we learned that they navigated to the workflow run logs provided by GitHub Actions
while trying to learn what the problem was with their submission.
The workflow run logs provide output from the internal workings of the system that is only of interest for developers
troubleshooting a malfunction of the system itself. We never intended to use them as a channel for communicating to the
regular users of the system. Users of the system may find them quite cryptic. Since this is an interface generated by
GitHub Actions, without much capability for customization, it would be quite difficult for us to improve their
readability for the normal user. Those efforts would also require an increase in the complexity of the workflow and make
it more difficult to maintain.
I think there are two possible paths a normal user would be likely to follow to the workflow logs while trying to
understand why their submission was not accepted:
- The check status UI shown at the bottom of the PR comment thread ("Some checks were not successful")
- Workflow run failure email notification ("Manage PRs: Some jobs were not successful: View workflow run")
These pathways are either less enticing or absent when a workflow run is successful.
Previously, there were two possible causes for a run of the "Manage PRs" workflow to fail:
- Submitted library did not meet the Library Manager requirements
- An unexpected error from one of the workflow steps
Since we already are using comments from the bot to communicate about the former, the workflow run failure status
indicators provided by GitHub Actions are superfluous. The latter only occurs under extraordinary and circumstances so
its effect on the user experience is not of concern.
So the way to improve the user experience is to configure the workflow to only fail on unexpected errors, only commenting
and blocking merge in the event of expected errors.
Hello!
I own the UbxGps library and it's been in the registry for a while, but with my previous GitHub username (1oginov).
I changed it to loginov-rocks and just aligning a link to the repository.
Link in the library.properties has already been updated: https://github.com/loginov-rocks/UbxGps/blob/main/library.properties#L8
Thank you!
