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.
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.
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.
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.
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.
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.
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.
Previously, the action could only install Task when the runner had an x86-64 or i386 architecture.
Since the GitHub-hosted runners are currently all x86-64, that is sufficient for most users. However, it is also
possible to use GitHub actions with self-hosted runners of other architectures. Task builds are available for more
architectures, so the action's code unnecessarily limited its utility.
Support for all architectures with available builds is hereby added.
In order to provide some possibility of automatic support for additional builds that may become available in the future,
if the action code does not contain a mapped value for the host architecture, the value from Node.js is used verbatim.
Because the mapping between the architecture value provided by Node.js to the filename suffix used in the Task build
archives is a bit confusing, I added mapping entries for all suffixes, even in the cases where the two values are equal.
Co-authored-by: Luca Bianconi <71259950+Bikappa@users.noreply.github.com>
