GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
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.
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.
GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
