-
-
Notifications
You must be signed in to change notification settings - Fork 403
Provide bash completion #124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
To test: arduino-cli generate_autocomplete > arduino-cli.sh source arduino-cli.sh Completion on fqbn is broken and wip
Should help discovering features "inline" (see arduino#138)
✅ Build completed. ⬇️ Linux 64: ⬇️ Linux 32: ⬇️ Linux ARM: ⬇️ Windows: ⬇️ OSX: ℹ️ To test this build:
|
Closing as code has diverged too much, adding it as a task in our backlog. |
…rkflow (#124) Use the matrix.include key to customize the compile-examples CI workflow's matrix jobs with board type-specific configurations. This GitHub Actions feature allows defining additional properties for matrix jobs that match the filter. The previous approach for doing this was to use generated environment variable names, which worked but seemed likely to be confusing for anyone trying to decipher the workflow. I think the new approach is a little easier to understand and less hacky. I had hoped this would allow me to do away with the board.type system, but supplying lists of values to the filter keys isn't supported, you can't reference the env key from matrix, and YAML anchors aren't supported. So the board.type system remains the only way I can see to avoid redefining the configuration options for each board of the same type.
…rkflow (#124) Use the matrix.include key to customize the compile-examples CI workflow's matrix jobs with board type-specific configurations. This GitHub Actions feature allows defining additional properties for matrix jobs that match the filter. The previous approach for doing this was to use generated environment variable names, which worked but seemed likely to be confusing for anyone trying to decipher the workflow. I think the new approach is a little easier to understand and less hacky. I had hoped this would allow me to do away with the board.type system, but supplying lists of values to the filter keys isn't supported, you can't reference the env key from matrix, and YAML anchors aren't supported. So the board.type system remains the only way I can see to avoid redefining the configuration options for each board of the same type.
…flow [skip changelog] Add workflow to test install script
To test:
Completion on fqbn is broken and wip