1
0
mirror of https://github.com/arduino/library-registry.git synced 2025-07-09 01:42:00 +03:00
Commit Graph

109 Commits

Author SHA1 Message Date
5d935c3b7c Don't upload multiple times to same artifact in "Manage PRs" workflow
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.
2024-11-01 05:41:55 -07:00
4a42992908 Don't upload multiple times to same artifact in label sync workflow
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.
2024-11-01 05:41:39 -07:00
dfb6a0cc83 Bump geekyeggo/delete-artifact from 2 to 5
Bumps [geekyeggo/delete-artifact](https://github.com/geekyeggo/delete-artifact) from 2 to 5.
- [Release notes](https://github.com/geekyeggo/delete-artifact/releases)
- [Changelog](https://github.com/GeekyEggo/delete-artifact/blob/main/CHANGELOG.md)
- [Commits](https://github.com/geekyeggo/delete-artifact/compare/v2...v5)

---
updated-dependencies:
- dependency-name: geekyeggo/delete-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2024-11-01 05:41:24 -07:00
1084031aba Bump actions/download-artifact from 3 to 4
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 3 to 4.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](https://github.com/actions/download-artifact/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2024-11-01 05:41:08 -07:00
67761062a3 Bump actions/upload-artifact from 3 to 4
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 3 to 4.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](https://github.com/actions/upload-artifact/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2024-11-01 12:37:41 +00:00
4713c34a09 [skip-changelog] Configure actions/upload-artifact action to upload required hidden files
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.
2024-09-04 15:53:15 +02:00
e301854e59 Don't limit number of open Dependabot pull requests
The Dependabot service is used to keep the project dependencies updated.

Thanks to the project's high quality validation infrastructure, the human effort required to complete a trivial version
bump is minimal. However, some bumps may introduce breaking changes that would require a significant amount of effort to
accommodate, or are blocked by external tasks. In this case, the Dependabot pull request can't be merged, but should be
left open to track the need to perform the bump when it is feasible. This means that it should be expected that there
will be regularly be a small number of Dependabot pull requests left open in the repository over long periods of time.
The automated system is here to assist the human project maintainers, not as a tyrannical overlord, so this is the
system working exactly as intended.

By default, Dependabot is configured to stop submitting pull requests if it already has five open pull requests. This
means that if it happens that the accumulation of intentionally on-hold pull requests reaches that number, the project
stops receiving the easily handled trivial update PRs. This is very harmful because it results in the completely
unnecessary use of outdated dependencies, and unnecessary challenging large bumps when pull requests start being
submitted once more after the backlog is cleared.

The harmful default configuration is hereby overridden by configuring the maximum open pull request limit at 100. This
value was chosen as an arbitrary large number simply to functionally disable the limiting, rather than from any
expectation that the actual number of open PRs can ever reach that count.
2024-06-13 11:22:19 -07:00
4a8f1c42e1 Automatically assign per1234 to Dependabot PRs
As the primary maintainer of the project infrastructure, it is the responsibility of GitHub user per1234 to review and
merge the pull requests automatically submitted by Dependabot for bumps of outdated project dependencies.

Configuring Dependabot to automatically set the pull request assignment will slightly streamline that process.
2024-06-13 11:22:04 -07:00
2055a9640d Bump xt0rted/markdownlint-problem-matcher from 2 to 3
Bumps [xt0rted/markdownlint-problem-matcher](https://github.com/xt0rted/markdownlint-problem-matcher) from 2 to 3.
- [Release notes](https://github.com/xt0rted/markdownlint-problem-matcher/releases)
- [Changelog](https://github.com/xt0rted/markdownlint-problem-matcher/blob/main/CHANGELOG.md)
- [Commits](https://github.com/xt0rted/markdownlint-problem-matcher/compare/v2...v3)

---
updated-dependencies:
- dependency-name: xt0rted/markdownlint-problem-matcher
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2024-02-26 01:44:04 +00:00
be21fe30c8 Bump actions/checkout from 3 to 4
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v3...v4)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2023-09-05 01:49:23 +00:00
89b364fbe9 Bump carlosperate/download-file-action from 1 to 2
Bumps [carlosperate/download-file-action](https://github.com/carlosperate/download-file-action) from 1 to 2.
- [Release notes](https://github.com/carlosperate/download-file-action/releases)
- [Commits](https://github.com/carlosperate/download-file-action/compare/v1...v2)

---
updated-dependencies:
- dependency-name: carlosperate/download-file-action
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-10-25 01:12:02 +00:00
a8d3b70bf9 Bump xt0rted/markdownlint-problem-matcher from 1 to 2
Bumps [xt0rted/markdownlint-problem-matcher](https://github.com/xt0rted/markdownlint-problem-matcher) from 1 to 2.
- [Release notes](https://github.com/xt0rted/markdownlint-problem-matcher/releases)
- [Changelog](https://github.com/xt0rted/markdownlint-problem-matcher/blob/main/CHANGELOG.md)
- [Commits](https://github.com/xt0rted/markdownlint-problem-matcher/compare/v1...v2)

---
updated-dependencies:
- dependency-name: xt0rted/markdownlint-problem-matcher
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-10-24 01:34:25 +00:00
191d6569ba Bump geekyeggo/delete-artifact from 1 to 2
Bumps [geekyeggo/delete-artifact](https://github.com/geekyeggo/delete-artifact) from 1 to 2.
- [Release notes](https://github.com/geekyeggo/delete-artifact/releases)
- [Commits](https://github.com/geekyeggo/delete-artifact/compare/v1...v2)

---
updated-dependencies:
- dependency-name: geekyeggo/delete-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-10-13 01:07:00 +00:00
90bb1247cc Configure link check to use Accept-Encoding header for docs.github.com links
The link check job of the "Check Markdown" workflow has had frequent intermittent spurious failures recently, caused by
links under the docs.github.com domain returning 403 HTTP status.

Others experiencing the same problem reported that they were able to work around the problem by providing a custom
`Accept-Encoding` HTTP request header. Although I was not able to find any explanation of why, it does appear to resolve
the problem.

Since the problem seems to be permanent and the only other workarounds I have identified are unappealing (considering
links returning 403 statuses alive, or ignoring all docs.github.com links), I think it is worth a try.
2022-05-30 09:07:39 -07:00
c69b815a85 Use form-based issue templates
High quality feedback via GitHub issues is a very valuable contribution to the project. It is important to make the
issue creation and management process as efficient as possible for the contributors, maintainers, and developers.

Issue templates are helpful to the maintainers and developers because it establishes a standardized framework for the
issues and encourages the contributors to provide the essential information.

The contributor is now presented with a web form when creating an issue. In the case of the library registration
maintenance requests, these are for the specific information the registry maintainers require. For more general bug
reports or feature requests, they use multi-line input fields that have the same formatting, preview, and attachment
capabilities as the standard GitHub Issue composer, in addition to other form components such as menus and checkboxes
where appropriate.

The use of this form-based system should provide a better experience for the contributors and library maintiners while
also resulting in higher quality issues by establishing a standardized framework for the issues and encouraging
contributors to provide the essential information.

A template chooser allows the contributor to select the appropriate template type, redirects support requests to the
appropriate communication channels via "Contact Links", and provides a prominent link to security policy to guide any
vulnerability disclosures.

The clear separation of the types of issues encourages the reporter to fit their report into a specific issue category,
resulting in more clarity. Automatic labeling according to template choice allows the reporter to do the initial
classification.
2022-05-10 23:19:30 -07:00
a506c42c15 Merge pull request #1286 from arduino/dependabot/github_actions/actions/upload-artifact-3
Bump actions/upload-artifact from 2 to 3
2022-04-11 03:44:38 -07:00
5a17e6af8f Bump actions/download-artifact from 2 to 3
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 2 to 3.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](https://github.com/actions/download-artifact/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-04-11 01:26:14 +00:00
14973cfc77 Bump actions/upload-artifact from 2 to 3
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 2 to 3.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](https://github.com/actions/upload-artifact/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-04-11 01:26:10 +00:00
c1ff2b807c Remove notes field from label configuration file
At the time the reference configuration file was developed, it was in JSON, which does not support comments. I found the
need to add some internal explanatory commentary to some of the labels, so I added an arbitrary `notes` key as a
container for this information, and our JSON schema was also configured to accept this field.

I later decided to convert the files to YAML, since that is the language used by the majority of the asset configuration
files. At this point it became possible to use comments, but the `notes` field was already in place so it
seemed pointless to change it.

Validation of the configuration file was added to the "GitHub Label Sync" tool in the recent 2.1.0 release. Before
2.1.0, the tool ignored any additional properties in the label configuration objects. It now errors if there are any
unexpected properties.

This `notes` field now causes the configuration files that contain it to be considered invalid by the tool, and by our
custom JSON schema:

```
.github/label-configuration-files/labels.yml invalid
[
  {
    instancePath: '/8',
    schemaPath: '#/items/additionalProperties',
    keyword: 'additionalProperties',
    params: { additionalProperty: 'notes' },
    message: 'must NOT have additional properties'
  }
]
```

So the `notes` field is hereby removed, with the contents moved to comments.
2022-03-31 01:34:20 -07:00
dd55ef3d71 Configure documentation links to allow localization
github.com and wikipedia.org have different localization behaviors depending on the URL.

If a language code is specified via the URL, then that language version of the page is loaded, regardless of the language setting of the user's browser or GitHub. For example, this URL will take the user to the English version of the page even if their browser is configured for Chinese:

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github

If no language code is specified via the URL, then it redirects to the version of the page localized for the user's language preference, where available. For example, if the user has selected "Chinese" as their preferred language in their browser settings, then this URL:

https://docs.github.com/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github

redirects to:

https://docs.github.com/cn/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github
2022-03-12 10:48:36 -08:00
c4b54cdb9c Bump actions/checkout from 2 to 3
Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-03-02 01:12:21 +00:00
3c5d83bf24 Add "pending backend" repository label
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.
2021-12-21 07:35:45 -08:00
822401d23b Use major version ref of carlosperate/download-file-action
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.
2021-12-19 20:12:45 -08:00
abec5ec873 Avoid manager workflow run cancelation by incidental events
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.
2021-12-07 13:17:48 -08:00
d8a62fddc4 Configure manager workflow to prevent parallel runs for one PR
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.
2021-11-22 23:46:43 -08:00
722de10710 Merge pull request #580 from per1234/sync-labels-fix
Fix bugs in dry run determination code for "Sync Labels" workflow
2021-10-13 01:50:50 -07:00
3ec30a80ba Sync labels in write mode on schedule trigger
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.
2021-10-12 16:06:05 -07:00
baa0c087f5 Correct context key name in "Sync Labels" workflow
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.
2021-10-12 16:05:46 -07:00
b5807e8d6a Add type change repository label to configuration file
The repository contains labels for each of the distinct operations that may be requested for the library registrations or index data. These labels are defined in a local configuration file for management by the "Sync Labels" GitHub Actions work in combination with the shared universal Arduino tooling project repository labels configuration file.

Since there has not yet been an internal request for a type change operation, the associated "topic: type change" label was forgotten when creating the configuration file. It will be best to have the label in place so every standard operation can be accomplished without unnecessary complication.
2021-10-12 09:11:40 -07:00
d82d249108 Add CI workflow to synchronize with shared repository labels
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.
2021-09-28 21:46:30 -07:00
6d4b71f5d4 Handle submission merge failures caused by outdated fork
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.
2021-09-14 06:40:53 -07:00
7e60e814bc More clearly communicate that new PR is not required to resolve submission problem
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.
2021-09-01 00:38:57 -07:00
fa2bb2b4b8 Bump arduino/library-manager-submission-parser version
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.
2021-08-26 03:36:25 -07:00
4f3aca6dee Sync CI configuration files with templates
Some minor adjustments to the comments in the configuration files for the tools used by the repository's CI system to
bring them into sync with the upstream "template" assets.
2021-08-11 03:52:02 -07:00
d5842c1cfe Enhance "Check License" workflow's error output
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.
2021-08-11 03:39:45 -07:00
579360761f Use conservative env var brace wrapping in "Check License" workflow
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.
2021-08-11 03:39:45 -07:00
e0c4b766d5 Always check both license filename and type in "Check License" workflow
This might provide some additional useful context to the reader in the event of a failure.
2021-08-11 03:39:45 -07:00
e9352f1e53 Make "Check License" workflow path filter handle either YAML extension
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.
2021-08-11 03:39:45 -07:00
0c1daad6e9 Remove reference comment from "Check License" workflow
Although very useful information, it doesn't apply directly to the licensee commands being run in this workflow step, and
thus might be confusing.
2021-08-11 03:39:45 -07:00
60c38f547a Add manual events as "Check License" workflow triggers
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.
2021-08-11 03:39:45 -07:00
a5ae9a22af Add source URL comment to "Check License" workflow
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream
"template" workflow and its installation in this repository.
2021-08-11 03:39:45 -07:00
c8625b7cd7 Use standardized workflow/job/step names in "Check License" workflow
These are the naming conventions established in the standardized template workflow.
2021-08-11 03:39:44 -07:00
6a270f76f5 Require that PR head matches that of diff when merging
Due to the limitations imposed by by using both `pull_request_target` and `issue_comment` events to trigger the
"Manage PRs" workflow, the PR diff used for the validation is procured via a GitHub API request.

It is necessary to check that the pull request state matches that of the diff, which is achieved via the `sha` parameter
of the GitHub API request used to merge. This can not be determined from the `github` context provided by GitHub Actions
to the workflow for either of the trigger events, so the pull request metadata is requested from the GitHub API at the
same time as the diff.

This situation requires different handling by the `merge-fail` job. Fortunately, the two failure causes result in
different values from the merge request workflow step's `status` output.
2021-07-29 20:26:21 -07:00
03bdfa7974 Reduce likelihood of spurious merge conflict bot comment
Previously, the "Manage PRs" workflow made a comment suggesting to resolve the merge conflict after any failure to merge
a pull request. This comment is worded in a way that makes it somewhat applicable to other causes, but still might cause
the submitter to waste time unnecessarily trying to figure out how to merge a nonexistent merge conflict when the failure
had a different cause.

The 405 response is not specific to a failure due to merge conflict, but I believe that all failures due to merge
conflict will result in a 405. This means that the check is not perfect, but will make spurious mentions of merge
conflict resolution less likely at least.

A review is requested from a maintainer any time the merge fails, so they will be able to investigate and provide
assistance if necessary.
2021-07-29 20:10:56 -07:00
227b7d92b2 Merge pull request #282 from per1234/bump-parser
Bump library registry submission parser version used by "Manage PRs" workflow
2021-07-26 06:21:07 -07:00
014305a2cc Bump library registry submission parser
A new 1.1.0 version of `arduino/library-registry-submission-parser` is now available.
2021-07-26 06:16:25 -07:00
f8385ae72b Handle general problems with pull request
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.
2021-07-24 08:59:00 -07:00
c674fc0225 Add a dedicated "Manage PRs" workflow job for review request
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.
2021-07-24 06:14:45 -07:00
ec4a8a8be1 Use a variable to define error message prefix
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.
2021-07-24 06:14:45 -07:00
f67d72a764 Merge pull request #231 from per1234/unlink-mention
Avoid linkification of bot user name in comment
2021-07-20 00:56:58 -07:00