Description
The scope of the initial phase of this project was limited to assets of use for Go-based tooling projects.
There is a collection of assets that did not fall under that scope, which are currently hosted provisionally here:
https://github.com/per1234/.github/tree/main/workflow-templates
Some of these might be of use for tooling projects. If so, it would be beneficial to host them in this repository where they will be more visible to the team and easier to maintain.
They fall into several general categories:
JavaScript/TypeScript
These are probably of the most interest since JavaScript/TypeScript is the other major language of Arduino's tooling projects, yet arduino/tooling-project-assets does not currently contain any assets specifically for these languages.
Some of these assets are already in use in tooling projects (arduino/arduino-lint-action, arduino/setup-task).
The available assets mostly use two project management frameworks:
- npm
- Task
The use of Task in this context is perhaps unusual. It was chosen for arduino/setup-task because it seemed appropriate to use Task itself for a project devoted to Task. I don't know whether there is interest in taking this approach for any other projects.
npm is in use in several tooling projects, so those are likely of more value.
Firmware targeted
These will be applicable only to firmware projects. However, they are used for the deployment of Arduino's GitHub Actions actions, and so are at least tooling-related.
Standalone
Go-based tooling projects use the Task task runner for all development operations. The "template" GitHub Actions workflows in this repository are based around running those tasks.
This is the right approach for a project that is based around Task because it means that the local development operations are identical to those run by the automated systems. However, not all projects are. For those, the use of Task solely for the CI/CD system is not appropriate. In this case, it can make sense to use standalone GitHub Actions workflows that are exclusively for automated processes.
Notes
The workflows themselves are reasonably refined, so I don't foresee a lot of work being required on any that might be chosen for migration . There is also fairly comprehensive documentation, but a significantly improved template documentation structure evolved through the refinement of the arduino/tooling-project-assets content, and the documentation in per1234/.github has not been brought up to that standard. I think that would be important to do for the sake of consistency across the documentation content in this repository.