Skip to content

Conversation

@per1234
Copy link
Contributor

@per1234 per1234 commented May 12, 2020

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:
https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix

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 by GitHub Actions. 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

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.
@github-actions
Copy link

Memory usage change @18343c67c95c9a50fbda63a103bda9711a5ee3f4

FQBN Flash Usage RAM For Global Variables
arduino:samd:mkr1000 0 0
arduino:samd:mkrgsm1400 0 0
arduino:samd:mkrnb1500 0 0
arduino:samd:mkrwan1300 0 0
arduino:samd:mkrwifi1010 0 0
arduino:samd:nano_33_iot 0 0
esp8266:esp8266:huzzah 0 0

Copy link
Contributor

@aentinger aentinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@aentinger aentinger merged commit e888adb into arduino-libraries:master May 13, 2020
aentinger pushed a commit that referenced this pull request May 13, 2020
…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.
@per1234 per1234 deleted the workflow-matrix-include branch May 13, 2020 09:10
aentinger pushed a commit that referenced this pull request May 13, 2020
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants