Sync integration test assets from "templates" #63
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the template workflow filename, which is intended to serve as a unique identifier within a collection that might include multiple related variants, and thus must be a bit more verbose.
No functional change, and neither is necessarily superior, but this is how it is in the "template", and so it must be here as well. `tests` seems to be slightly more common, but there are prominent Python projects using either.
…nsion 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.
This is the naming convention established in the standardized template workflow. The tool name is "Task", with "taskfile" being its configuration file, so the previous step name was inaccurate.
The badges provide a prominent indication of the repository's CI status at a glance. This may help to bring potential issues to the attention of the maintainers.
…nstall The tasks called from the `deps` key of a task are run in parallel. Once they are finished, the commands from the `cmds` key are run in serial. In the case of tasks that don't depend on the output from another, this can make the task more efficient. Such is the case with the `go:test-integration` task. The Go application must be built and the Python testing dependencies installed before the tests can run, but those two task dependencies can run in parallel.
This is the conventions established in the standardized template task.
This is the command used in the standardized "template" task that should be used in all Go projects. The previous `GO_BUILD_FLAGS` variable was intended to allow the developer to specify arbitrary arguments via the command line, but that is not needed. The `LDFLAGS` variable that is introduced here allows injecting data to the build, which is used in more complex applications, but not in this one at the moment.
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream "template" assets and their installation in this repository.
per1234
added
type: enhancement
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have assembled a collection of reusable project assets:
https://github.com/arduino/tooling-project-assets
These will be used in the repositories of all Arduino tooling projects.
Some minor improvements and standardizations have been made in the upstream "template" assets, and those are introduced to this repository via this pull request.