This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
The previous URL was for the original privilege revocation. Since they chose to continue their irresponsible behavior
instead of making a privilege restoration request as was detailed in the original revocation notification, the
revocation is now permanent. Thus it does not make sense to link to the original notification which contains a
restoration offer.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
These users (both accounts are the same entity) has established a pattern of irresponsible behavior in the Arduino
Library Manager Registry repository. They continued this behavior even after the bot and human maintainer made
significant efforts to guide them to responsible use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
`github.com/ajangrahmat` has established a pattern of irresponsible behavior in the Arduino Library Manager Registry
repository, related to the libraries of the associated organization `github.com/kelasrobot`. They continued this
behavior even after the bot and human maintainer made significant efforts to guide them to responsible use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
Background
----------
The Arduino Library Manager Registry repository receives thousands of pull requests from a large number of community
contributors. The great majority of these contributors behave in a responsible manner. Unfortunately this repository is
regularly the subject of irresponsible behavior. The small number of people who behave irresponsibly consume a
significant amount of the finite maintenance resources available for maintenance of Arduino's repositories.
Communication is always the first measure taken in these cases. This is done automatically by the "Manage PRs" workflow,
and then by the registry maintainer when it becomes clear that the user has disregarded the comments from the bot.
Unfortunately it is regularly the case that the user simply disregards all communication and continues their pattern of
irresponsible behavior unchecked.
Alternatives
------------
GitHub provides tools for dealing with harmful behavior:
- Report user
- Block user
Reporting a user is the appropriate measure in cases of malicious behavior, and the account is usually banned from the
site relatively quickly after a legitimate report is made. However, the irresponsible behavior in the registry
repository is not overtly malicious and so reporting the user in these cases would not be appropriate or effective.
At first glance, the block feature seems ideal. However, it can only be done at an organization-wide level, and by an
organization administrator. The repository maintainer is not an organization administrator, so this makes the feature
inconvenient to use. There is no sign of these users interacting with other repositories in the `arduino` organization,
and so there is no benefit to blocking them at organization scope. In addition, in order to make it more difficult to
circumvent the access restriction, we need the ability to block requests for libraries owned by an entity who has
established a pattern of irresponsible behavior, regardless of which user submits the request.
So the tools provided by GitHub are not suitable and a bespoke system must be implemented.
Access Levels
-------------
Allow: the user may submit requests for any library, even if registry privileges have been revoked for the owner of the
library's repository. This access level will only be granted to registry maintainers, in order to allow them to make
exceptions for specific libraries owned by an entity whose privileges have been revoked.
Default: the user may submit requests for any library, unless registry privileges have been revoked for the owner of the
library's repository.
Deny: the user may not submit requests. Requests from users with "default" access level for any library repository owned
by the entity (user or organization) are denied.
In cases where a request is declined due to revocation of Library Manager Registry privileges, the "Manage PRs" workflow
will automatically make an explanatory comment, including a link that provides more details about the cause of the
revocation. It will also close the PR in the case where it is not possible for the requester to resolve the problem:
* The requester's Library Manager Registry privileges have been revoked
**-OR-**
* The owners of all library repositories which are the subject of the request have lost Library Manager Registry
privileges.
The "Manage PRs" GitHub Actions workflow uses a command line tool named "library-registry-submission-parser" to parse
the pull requests submitted to this repository.
A new version of "library-registry-submission-parser" has been released, and so the version specified in the workflow
for use is hereby updated.
Two additional mandatory flags have been added to the command line interface of library-registry-submission-parser, so
these flags are added to the invocation, and an access control configuration file added to the repository as required
for use with the new `--accesslist` flag. To start, the access control configuration file is left empty, giving all
users default access privileges as before. The workflow will be adjusted to take advantage of the newly added access
control capabilities of library-registry-submission-parser in a separate commit.
Since it is intuitive and commonly used, the default behavior of the actions/checkout GitHub Actions action when a
workflow is triggered the "pull_request" or "push" events is well understood by any workflow maintainer. However, the
default behavior of the action when the workflow is triggered by a "pull_request_target" or "issue_comment" event (as is
the case for the "Manage PRs" workflow) is not obvious and less well known since these events are more rarely used.
It is important for the maintainer to understand which Git ref will be checked out by the actions/checkout action steps
in the "Manage PRs" workflow. Adding an explanatory comment will help to ensure they have this understanding.
The `check-submissions` job of the "Run integration tests" GitHub Actions workflow is configured to generate multiple
parallel jobs, one for each of the submitted libraries. The subsequent jobs must be able to determine whether any of the
libraries failed the checks. This is done by the matrix jobs in which checks failed uploading a flag file to a GitHub
Actions workflow artifact, then the subsequent jobs checking for the presence of an artifact. The
"actions/upload-artifact" and "actions/download-artifact" actions are used for this purpose.
Previously, a single artifact was used for all flag files, with each of the parallel jobs uploading its flag file to
that single artifact. However, support for uploading multiple times to a single artifact was dropped in version 4.0.0 of
the "actions/upload-artifact" action. So it is now necessary to use a dedicated artifact for each of the parallel jobs.
These artifacts can be downloaded in aggregate by using the artifact name globbing feature which was introduced in
version 4.1.0 of the "actions/download-artifact" action.
The "Sync Labels" GitHub Actions workflow is configured to allow the use of multiple shared label configuration files.
This is done by using a job matrix in the GitHub Actions workflow to download each of the files from the source
repository in a parallel GitHub Actions workflow job. A GitHub Actions workflow artifact was used to transfer the
generated files between sequential jobs in the workflow. The "actions/upload-artifact" and "actions/download-artifact"
actions are used for this purpose.
Previously, a single artifact was used for the transfer of all the shared label configuration files, with each of the
parallel jobs uploading its own generated files to that artifact. However, support for uploading multiple times to a
single artifact was dropped in version 4.0.0 of the "actions/upload-artifact" action. So it is now necessary to use a
dedicated artifact for each of the builds. These can be downloaded in aggregate by using the artifact name globbing and
merging features which were introduced in version 4.1.0 of the "actions/download-artifact" action.
A breaking change was made in the 3.2.1 release of the "actions/upload-artifact" action, without doing a major version
bump as would be done in a responsibly maintained project. The action now defaults to not uploading "hidden" files.
The when the workflows fails it stores information in a file called `.check-submissions-failed`.
The `.` at the start of the `.check-submissions-failed` folder name causes it to now not be uploaded to the workflow artifact. In order
to catch such problems, the workflow configures the "actions/upload-artifact" action to fail if no files were uploaded.
So in addition to not uploading the artifact, the change in the "actions/upload-artifact" action's behavior also
resulted in the workflow runs failing:
Error: No files were found with the provided path: /home/runner/work/_temp/.check-submissions-failed. No artifacts will be uploaded.
The problem is fixed by disabling the "actions/upload-artifact" action's new behavior via the `include-hidden-files`
input. After this change, the workflow can once more upload the check-submission-failed file to a workflow
artifact as needed.
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.
It was previously possible to trigger the "Manage PRs" workflow for a pull request while a previous run for that PR is
already in process.
When that happens, it can result in erroneous bot comments. For example:
1. Workflow run is automatically triggered by a push.
2. Contributor does not notice this and comments a mention of the bot to trigger the workflow.
3. The first workflow run finds the PR is compliant and merges it.
4. The second workflow run finds the PR is compliant and attempts to merge it.
5. The second workflow run fails the merge (because it is already merged) and informs the contributor that there was a
merge conflict they must resolve.
6. The contributor is not able to resolve the non-existent conflict and is left wondering whether their submission was
successful.
The solution is to configure the "Manage PRs" workflow so that a workflow run in progress is canceled if the workflow is
triggered again for that PR. The "concurrency group" name is the PR number, so workflow runs in progress for other PRs
would not be affected.
In order to facilitate the testing and review of proposed changes to the repository label infrastructure, the
"Sync Labels" template workflow does a dry run when triggered under conditions that indicate it would not be appropriate
to make real changes to the repository's labels. The changes that would have resulted are printed to the log, but not
actually made.
One of the criteria used to determine "dry run" mode usage is whether the event occurred on the repository's default
branch. A trigger on a development branch or for a pull request should not result in a change to the labels.
It turns out that GitHub does not define a `github.event.repository.default_branch` context item when a workflow is
triggered by a `schedule` event. This resulted in the workflow always running in "dry run" mode on a `schedule` trigger.
Since `schedule` and `repository_dispatch` triggers are only permitted for the default branch, there is no need to check
whether the event's ref matches the default branch and it is safe to always run in write mode on these events.
Incorrect context key name resulted in impossible to satisfy conditional, meaning the dry run determination code was
solely dependent on the check for whether the workflow was triggered from the default branch name.
On every push that changes relevant files, and periodically, configure the repository's issue and pull request labels
according to the universal, shared, and local label configuration files.
The automatically generated access token provided by `${{ secrets.GITHUB_TOKEN }}` is used to automatically merge
submission pull requests if they are compliant with all requirements.
If the pull request's branch is behind the parent repository and the code of any GitHub Actions workflow has been
modified in the parent since that time, the token permissions are downgraded, which causes the GitHub API request for
merging the PR to fail with a 403 status.
Previously, this was treated as an unexpected merge failure caused by some problem not resolvable by the PR author. Since
the PR author can easily resolve the failure by bringing their branch up to date (even through the GitHub web interface),
the "Manage PRs" workflow is hereby changed to provide instructions for doing so.
As before, a review will be requested from the maintainer of this repository so that they can monitor the situation and
provide the PR author with assistance if needed.
The system is designed to allow a submission to be accomplished in a single pull request. This is the case even when
initial passes of checks reveal problems that block acceptance. The checks will automatically re-run any time the PR
author pushes to the PR's branch or mentions the bot.
Although the submitters are welcome to submit a new PR if that is their preference, it is a less efficient approach, both
for them and the maintainer. So it's important to clearly communicate that the submission process can be continued via
the current PR if that is convenient to them.
Usage patterns indicate that this is not clearly communicated via the current messaging from the bot, so perhaps an
additional note with some styling to give it emphasis will improve on the user experience.
A new release of the `arduino/library-manager-submission-parser` tool used by the "Manage PRs" workflow has been made.
This release fixes a bug that caused pull requests that consisted only of newlines to be incorrectly classified as
"modification", resulting in an unexpected failure of the workflow run due to there being no library URLs to populate the
`check-submissions` job matrix:
```
Error when evaluating 'strategy' for job 'check-submissions'. (Line: 219, Col: 21): Unexpected value ''
```
These pull requests will now be assigned the appropriate "other" request type and the workflow run will pass as expected,
requesting the necessary manual review from a maintainer.
The use of the `error` workflow command will cause the important error message output to be surfaced prominently in the
workflow run summary and log. The workflow run logs can be somewhat labyrinthine to those who don't work with them
regularly, so finding the previous output to determine what caused the failure might have been challenging.
Even if it works as intended, it is not clear what the effect is of the escaped quote at the end of the environment
variables in the shell commands used to check the license detection results. Wrapping the variable names in braces
ensures they are as expected and also makes the working of the code clear.
There are two file extensions in common use for YAML files: `.yaml` and `.yml`. Although this project uses `.yml`
exclusively for YAML files, this is a standardized workflow which might be applied to projects that have established the
use of the other extension. It will be most flexible if it supports both.
The `workflow_dispatch` event allows triggering the workflow via the GitHub web interface. This makes it easy to trigger
an immediate workflow run after some relevant external change.
The `repository_dispatch` event allows triggering workflows via the GitHub API. This might be useful for triggering an
immediate check in multiple relevant repositories after an external change, or some automated process. Although we don't
have any specific need for this event at the moment, the event has no impact on the workflow, so there is no reason
against having it. It is the sort of thing that can end up being useful if it is already in consistently in place, but
not worth setting up on demand, since the effort to set it up is greater than the effort to trigger all the workflows
manually.
