use the values from matrix.json in plugin react tests

[evgeni]

No description provided.

[evgeni]

Why does this only trigger the "last" entry in the include matrix…

[evgeni]

According to the logs, it's correct:

##[debug]..=> 'matrix'
##[debug]=> '{"ruby": ["2.7"], "node": ["14"], "include": [{"repo": "foreman-tasks", "org": "theforeman"}, {"repo": "katello", "org": "Katello"}]}'
##[debug]Result: '{"ruby": ["2.7"], "node": ["14"], "include": [{"repo": "foreman-tasks", "org": "theforeman"}, {"repo": "katello", "org": "Katello"}]}'

[ekohl]

I think include won't do here. Isn't this essentially adding another vector to the matrix?

Perhaps it would also be easier if we simply had repo as fully qualified. So theforeman/foreman-tasks and Katello/katello. For the exact paths it doesn't matter and makes other things easier.

[evgeni]

so turns out, include on an existing matrix, does overwrite things if it can (see https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#expanding-or-adding-matrix-configurations), so my intent to have

matrix:
  ruby: 2.7
  node: 14
  include:
    - repo: katello
    - repo: tasks

doesn't work, as the last entry in the include list wins.

this behaviour is different from when you have only the include statement (see https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#example-adding-configurations)

this is apparently totally intentional and expected.

[evgeni]

well, this at least works…

[ekohl]

Given we read the matrix multiple times, any thoughts on converging to a single large ci.yaml file? Also keeping #9871 in mind.

I've been thinking about moving all Foreman & Foreman plugins CI tests to GHA and write up an RFC for that.

[evgeni]

Given we read the matrix multiple times, any thoughts on converging to a single large ci.yaml file?

Certainly an optimization we can think of. Ritght now it wouldn't work as the triggers are different for the existing workflows (they filter on different paths), but we could question whether this is required or whether we should "always" run those.
But preferably not in this PR.

[evgeni]

@ekohl needs theforeman/gha-matrix-builder#1 to work :)

[evgeni]

I couldn't get it to run against my fork.
github.repository points at the target, so my branch name (github.head_ref) doesn't resolve here.
Maybe github.sha would work? But IMHO something we can fix later.

[ekohl]

Weird, in my testing this worked:

Suggested change

	base_matrix_url: "https://raw.githubusercontent.com/${{ github.repository }}/${{ github.base_ref }}/.github/matrix.json"
	base_matrix_url: "https://raw.githubusercontent.com/${{ github.repository }}/${{ github.ref_name }}/.github/matrix.json"

But maybe I was only testing on push in my own repo so I didn't notice.

[evgeni]

ref_name for this pr is 9881, I tried.

[ekohl]

https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables is a bit ambiguous. Perhaps this needs to be extracted (using non-trivial logic) from the PR. I'm more and more leaning to using actions/checkout by using https://github.com/actions/checkout#fetch-only-a-single-file

[evgeni]

yes, this is also my preference, I think

[ekohl]

I've opened theforeman/gha-matrix-builder#2 to start trying this out.

[ofedoren]

Maybe a stupid question, but shouldn't be plugin a variable here?..

[evgeni]

you mean {{ matrix.plugin }}? that contains a slash now and I kinda didn't want to find out which parts of the GHA Octopus do and which do not understand how to create folders correctly.

Given we're only testing one plugin at a time, there is nothing that prevents us from having it in a common folder.

[ekohl]

From testing this looks OK. Just a few small things.

[ekohl]

This now looks good to me.