The workflow is configured to run whenever any relevant file in the repository is changed. However, the results of the
workflow run are also dependent on the external environment it runs in, which include:
- The software running on the GitHub hosted GitHub Actions runner machines
- The GitHub Actions actions used by the workflow
- The dependencies that are installed by the workflow directly or via the GitHub Actions actions it uses
The workflow does not fully pin to a specific version of external tools. This was done in the interest of reducing the
maintenance burden of keeping the systems up to date. However, it also means that a new release of one of those tools
can cause the workflow runs to start failing (which might happen through an enhancement to that resource resolving a
false negative, or a defect causing a false negative).
When the repository file path trigger is used by itself, this sort of external breakage is only revealed when an
unrelated change triggers the workflow. That can be distracting even to a dedicated member of the project development
team, as well as confusing and discouraging to any contributor.
This type of change can be caught by adding a `schedule` event trigger that causes the workflow to run periodically in
addition to the other on-demand triggers. This allows the problem to be identified and resolved at the maintainer's
convenience, separate from the unrelated development work.
The "Check Go Dependencies" GitHub Actions workflow checks for dependencies with incompatible or unapproved license
types.
The dependency license metadata consumed by the "Licensed" tool is cached in the project repository, in a dedicated file
for each dependency.
The `check-cache` job of the workflow checks whether that cache is in sync with the project's current dependencies. It
does this by using the "Licensed" tool to update the cache and then a `git diff` command to check whether that resulted
in any changes (which would indicate it is out of sync).
Out of sync states could result from any of three distinct conditions:
- Missing metadata file
- Incorrect metadata file contents
- Superfluous metadata file
An incorrectly configured `git diff` command previously caused the last of these to be missed.
My first take at this system was simply using `git diff --exit-code` alone. That detects the last two, but misses the
first. I added the `git add --intent-to-add .` command to detect added files, but didn't realize that it caused the last
to be missed.
Superfluous files in the dependency license metadata cache won't actually interfere with its intended functionality, but
it is still important to avoid an accumulation of unused files.
The new commands will catch all three of the possible out of sync conditions by staging all changes that result from
the metadata cache update to the repository and then comparing those against the `HEAD` commit.
I considered an alternative approach which works just as well as the chosen one:
```
git add .
git diff --exit-code HEAD
```
However, I feel that the `--cached` flag makes the `git diff` command more self-explanatory.
- Use correct `actions/setup-go` reference for version in use
- Update redirecting GitHub docs URL to new location
- Configure GitHub docs URL to allow localization where available
This library has been renamed as "DFRobot_RS01" and moved to https://github.com/DFRobot/DFRobot_RS01.
There is an existing registration for "DFRobot_RS01" so the library will now be available for installation from Library Manager via that name..