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.
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.
* Add libraries for new RAKwireless modules
RAK13005-TLE7259-Library - RAKwireless library for RAK13005 LIN bus module with TLE7259 transceiver IC
RAK-MQx-Library - RAKWireless library for the WisBlock MQx Gas Sensor Modules
* Add RAK12010 library
Co-authored-by: beegee1962 <bernd.giesecke@rakwireless.com>
Removed https://gitlab.com/F-Schmidt/uulm-mcp23008. This is my first library which will be renamed and restructured. The new libraries uulm-mcp23008-core and uulm-mcp23008-user (or similar) will follow soon. They will also provide examples and have a much better documentation.
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.
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.
