The "Manage PRs" GitHub Actions workflow generates a matrix job for each library submitted by the PR. The default job
name is generated from the job's matrix object. This contains the complete submission data, which results in a long and
somewhat cryptic job name that can make the workflow run more difficult to interpret.
The only necessary information is the description of the job's purpose ("check") and the submission URL (multiple URLs
per PR are supported). A custom job name allows for only using this information in the job name.
The official policy is that anyone is allowed to submit any library to Library Manager, regardless of whether they have
any involvement with the development and maintenance of the library.
As someone very much involved in the submission process, I have always wondered this myself. So it is very important to
clearly document this.
Some of the wording of the existing documentation implied that only the owner of the library could submit it, so this
text has been adjusted as well.
The yamllint configuration advocates for keeping line lengths within 120 characters. While exceeding this length only
results in a warning, I think it is beneficial to stay within that limit when it is possible and doesn't have a harmful
effect. In that spirit, I have reduced the long lines where this was easily done. There remain a few that are either not
possible or else not reasonable to reduce, and that's OK.
After I set up caching in the template workflows, doubts were raised about whether it provided any benefits. I don't know
enough about this subject to make a call on that and I have been unable to get any more information on the subject.
Since the caching significantly increases the complexity of the workflows, which may make them more difficult to maintain
and contribute to, I think it's best to just remove all the caching for now. I hope to eventually be able to revisit this
topic and restore caching in any workflows where it is definitely beneficial.
On every push and pull request that affects relevant files, and periodically, run yamllint to check the YAML files of
the repository for issues.
The .yamllint.yml file is used to configure yamllint:
https://yamllint.readthedocs.io/en/stable/configuration.html
It will be helpful to the reader to be able to get an overview of the documentation content and quickly navigate to the
section of interest.
The table of contents are automatically generated using the markdown-toc tool.
Because it can be easy to forget to update the table of contents when the documentation content is changed, I have added
a CI workflow to check for missed updates to readme ToC. On every push or pull request that affects the repository's
documentation, it will check whether the table of contents matches the content.
At the time it was created, there was only one official Arduino development application: Arduino IDE. Since that time,
Arduino Web Editor and Arduino CLI have been created, both of which implement Library Manager in their own manners.
Previously, library submitters were not exposed to the internal workings of the Library Manager index generation system,
so they only needed to be concern with the public index file. Now the submitters will be interacting directly with the
Library Manager submission list. This might lead to some confusion between that list and the Library Manager index, so
it's important to be clear in the terminology used in the documentation.
It is essential to clearly communicate the Library Manager requirements to the submitters. Previously, these requirements
were scattered throughout the FAQ. Consolidating them into unified lists, then referencing that information from the
other parts of the documentation makes it easier for the user to learn what are the requirements and easier for the
documentation to be maintained.
An FAQ hosted in the `arduino/Arduino` repository's wiki:
https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ
has long served as the canonical guide for the traditional process for submitting libraries to the Library Manager index.
Now that the submission process and support for the process has been moved from `arduino/Arduino` to this dedicated
repository, it makes sense to also host the FAQ content here.
This commit imports the exact unmodified content of the FAQ from
819425389e
Dependabot will periodically check the versions of all actions used in the repository's workflows. If any are found to
be outdated, it will submit a pull request to update them.
NOTE: Dependabot's PRs will sometimes try to pin to the patch version of the action (e.g., updating `uses: foo/bar@v1`
to `uses: foo/bar@v2.3.4`). When the action author has provided a major version ref, use that instead
(e.g., `uses: foo/bar@v2`). Dependabot will automatically close its PR once the workflow has been updated.
More information:
https://docs.github.com/en/github/administering-a-repository/keeping-your-actions-up-to-date-with-dependabot
Now that the parser tool is moved out of the repository, it makes less sense to use the taskfile-based approach for the
CI infrastructure. In order to make the repository more contributor-friendly, the license checking system is now
confined to a single workflow file.
Now that the parser tool is moved out of the repository, it makes less sense to use the taskfile-based approach for the
CI infrastructure. In order to make the repository more contributor-friendly, the documentation and configuration
checking system is now confined to the .github subfolder.
Now that the parser tool is moved out of the repository, it makes less sense to use the taskfile-based approach for the
CI infrastructure. In order to make the repository more contributor-friendly, the spell checking system is now reduced to
a single workflow file.
This approach allows the diff to be written directly to a file, rather than needing to sanitize the contents of the
output from the octokit/request-action before writing it to the file via the shell.
The index source file contains the normalized URL and the metadata that can't be derived from the library releases
("types" data and locked name) for each of the libraries in the Library Manager index. It's most appropriate to store it
in the same repository as the submission list.
I had intended to test these out but didn't get around to it. The workflow_dispatch might be convenient, but it's not at
all essential since the same thing can be accomplished by commenting on the PR.
Rather that committing directly to the index source file repository, save the index entry to a workflow artifact, which
will be consumed by the system that updates the index source file.
With the current submission system, it's common for people to provide the tag/release URL rather than the repository
URL. I think it likely the same sort of thing will occur with the new system. Previously, a very naive check was done
for the path component of the URL to have two levels. It turns out that the Gitlab repository URLs have more levels than
that. The superior approach is to use `git ls-remote` to verify that the URL is a Git repository.
Submissions of libraries to the Arduino Library Manager index can be done by submitting a pull request adding repositor
URLs to the list. The submissions are checked for compliance wih the requirements for addition to the index and as soon
as they are passing the pull request is merged and the entries are pushed to the index source file.
