Use GitHub Actions matrix for integration tests

[x3c41a]

Summary

• Replace duplicated Westend/Polkadot test blocks with a matrix strategy so both runtimes run in parallel on separate runners
• Eliminates ~75 lines of duplication
• Each runtime gets full isolation, avoiding flaky cross-runtime state issues like fix(ci): route IPFS CLI commands through daemon API to avoid repo.lock #237

Test plan

• Verify both matrix jobs (Westend parachain, Polkadot solochain) appear in the Actions tab
• Verify they run in parallel and all tests pass
• Verify artifact names are unique per runtime on failure

[bkontur]

@x3c41a why is this hanging?

[x3c41a]

@x3c41a why is this hanging?

I guess rate limiting. I had rate limits before, they looked similar

[bkontur]

I guess rate limiting. I had rate limits before, they looked similar

looks like the github Configuration protect branch with required jobs name changed :)

[karolk91]

Suggested change

	- name: Test authorize-and-store ws
	working-directory: examples
	run: just run-test-authorize-and-store "${{ env.TEST_DIR }}" "bulletin-westend-runtime" "ws"
	run: just run-test-authorize-and-store "${{ env.TEST_DIR }}" "${{ matrix.runtime.package }}" "ws"
	- name: Test authorize-and-store ws
	env:
	RUNTIME_PACKAGE: ${{ matrix.runtime.package }}
	working-directory: examples
	run: just run-test-authorize-and-store "$TEST_DIR" "$RUNTIME_PACKAGE" "ws"

[bkontur]

@karolk91 why is this better approach? Then we need to adjust also other steps. Why not then add RUNTIME_NAME to echo "TEST_DIR=$TEST_DIR" >> "$GITHUB_ENV" or something like that, so we don't need to add env: RUNTIME_PACKAGE: ${{ matrix.runtime.package }} to every step?

but the actual version, looks also easy:

run: just run-test-authorize-and-store "${{ env.TEST_DIR }}" "${{ matrix.runtime.package }}" "ws"

any security concerns like we discussed yesterday?

[x3c41a]

@karolk91 thx for the suggestion, it opened the right discussion I believe!
I used @bkontur approach to avid adding env: ... at every matrix step

any security concerns?

+1 to previous question

[karolk91]

the general idea is to avoid using ${{ xxx }} substitutions especially in cases where these can be provided by external user as these may lead to command injections. This is because how github action will substitute values for these variables before "shell" can handle them.

There are some other levels of protections so in our specific case we are probably safe without these changes - but to be future proof and follow best practices, lets use ${{ }} via env (as this path will make sure that these are substituted by "shell" itself instead of special handling from github actions where some special characters etc that may lead to command injections)

[karolk91]

using something like

echo "RUNTIME_PACKAGE=${{ matrix.runtime.package }}" >> "$GITHUB_ENV"

doesn't solve the issue (in general) because we just moved ${{ }} to a different place

[karolk91]

Suggested change

	- name: Test authorize-and-store smoldot
	working-directory: examples
	run: just run-test-authorize-and-store "${{ env.TEST_DIR }}" "bulletin-westend-runtime" "smoldot"
	run: just run-test-authorize-and-store "${{ env.TEST_DIR }}" "${{ matrix.runtime.package }}" "smoldot"
	- name: Test authorize-and-store smoldot
	env:
	RUNTIME_PACKAGE: ${{ matrix.runtime.package }}
	working-directory: examples
	run: just run-test-authorize-and-store "$TEST_DIR" "$RUNTIME_PACKAGE" "smoldot"

[karolk91]

@x3c41a , lets merge it. I will address security concerns in a separate PR

Best practices for the record:
https://docs.github.com/en/actions/reference/security/secure-use#use-an-intermediate-environment-variable

Also, please lets avoid jumping to implementations in the future until we are all aligned in a discussion regarding some topic

[x3c41a]

@x3c41a , lets merge it. I will address security concerns in a separate PR

Best practices for the record: https://docs.github.com/en/actions/reference/security/secure-use#use-an-intermediate-environment-variable

Also, please lets avoid jumping to implementations in the future until we are all aligned in a discussion regarding some topic

Great doc! I think we should add it to our Claude /review skill for reference.

Happy to review your PR!