firecow: 'parallel' property type must be integer at test-only changes.parallel

I think I need more information to debug this. Can you paste the output as well? Which module are you running it with? Which “parallel” is it making reference to?

Oh, I see it: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/includes...

See comments 36 to 38 in #3418831: Test-only job → . Adding a value there makes it a bit more confusing in the GitLab UI, and it seems to be valid yaml/GitLab CI syntax, so I'm not sure what options we have that would not be disruptive for the GitLab CI users. I wonder if it's an issue with the "firecow" package.

Adding a value there makes it a bit more confusing in the GitLab UI... I'm not sure what options we have that would not be disruptive for the GitLab CI users. I wonder if it's an issue with the "firecow" package (https://github.com/firecow/gitlab-ci-local/issues)

I'm not sure at the moment, would need more testing and looking at the original root issue in Gitlab along with their parser library and test a few scenarios with firecow.

While I spend more time looking into that to determine where this needs to be fixed I do want to look at this quote from the original issue:

One thing I discovered is that if the main phpunit job has been customised to run with a parallel matrix then this is replicated into the 'test-only changes' job, and that means that each of the changed tests are run in every parallel stream. The jobs are duplicated and it is a waste of resources - we only want one 'test-only changes' job

Is that actually a valid assumption?

Grabbing the REDIS module (it is the only one I know off hand that uses parallel):

  parallel:
    matrix:
      - REDIS_INTERFACE:
          - PhpRedis
          - Predis
          - Relay

We are making the assumption that purging the parallel jobs being ignored is 'safe' in the name of resource consumption. What if the bug only occurs with one of the 3 interfaces? What if the values in the matrix are necessary for test run success? In fairness a lot of bugs will impact globally and we will save some time (assuming a value in the matrix is not required for a successful test run) however speaking as a maintainer (I have not needed parallel yet) the first time I hit this I'm re-adding parallel back into the test-only job and shaking my head in frustration that what would of been a 5 second click of a button turns into an hour long fix session.

Since "parallel" can have different use cases, like number of parallel processes running the same job, or parallel processes running with different options, the assumption that we did in the mentioned issue might be wrong. The example that you provide there is a great one, that would be lost with the current setup.

As there is a "loss" with the current approach, the job is a manual job, and the parallel option is not heavily used, I think that it might make sense to remove that line and document it in the https://project.pages.drupalcode.org/gitlab_templates/jobs/test-only-cha... page, in case somebody wants to keep the previous behavior (or bug, depends on how you look at it).

I'll put together a quick MR with this and we can continue the discussion.

Made the change and documented how to change the behavior if needed.

Looks good to me.

Still looking if I need to file this in firecow however that does not require this issue to remain open.

Yes I agree that removing the parallel: line makes sense. When I was working on the original issue I was not considering all of the uses of parallel. I do have a parallel matrix in Scheduler, to run the separate phpunit groups in different jobs, and with this MR and just two test files changed you can see that each of the five parallel jobs now run the same two changed tests:
https://git.drupalcode.org/project/scheduler/-/pipelines/248004
But I can customise the test-only job to remove parallel just like before

The issue is still RTBC but I made a couple of suggestions in the help page

Merged! Thanks for the issue/fix/tests/reviews.

Automatically closed - issue fixed for 2 weeks with no activity.