CI jobs duplication

[dkazanc]

In this branch which sets the CI for linting and job tasks checks the jobs are duplicated for some reason. For instance this job creates:

Python linters / Run linters (pull_request) 
HTTomo tests / Black (pull_request)

The first job always passes for some reason (doesn't do anything useful), while the second one actually runs. The same applies to the checklist checks.

[yousefmoazzam]

It's bizzare, but e576065 simply removed two newlines (one that is in the jobs field, which is what first made me think of that could be causing weird behaviour, a newline in a dict), and that somehow made the workflow only run the single job in that workflow file instead of running the duplicated jobs (black + task checker) https://github.com/DiamondLightSource/httomo/actions/runs/9961613239/job/27523523400

However, with that commit being pushed, there's duplicated jobs from the "Python linters" workflow:

Python linters / Run linters (pull_request)
Python linters / Black (pull_request) 

so some more weirdness is afoot...

[yousefmoazzam]

Ok, it looks like the change in a94eff8 has made the duplicated job for the linter not be created anymore, see this instance of the "Lint" workflow now only triggering a single job (as expected) https://github.com/DiamondLightSource/httomo/actions/runs/9962231917/job/27525530864?pr=386.

(The change was running black in a github action as recommended by the black docs, as opposed to using the wearerequired/lint-action action which was older and had the node16 warning due to its last release being in Jan 2023 - somehow this "magically" made the issue go away, maybe the node16 warnings cause weird behaviour in certain cases, who knows...)

[yousefmoazzam]

Aww man, when I changed the title of the PR, the task checker action was triggered, and that caused the duplicate job to appear again... https://github.com/DiamondLightSource/httomo/pull/386/checks?check_run_id=27525980996

Perhaps this is also related to how the status checks are setup, because in the text of the workflow being triggered:

HTTomo tests / Task Completed Checker (pull_request)

the format of that typically is:

workflow_name / job_name

but I can't see any job with the name "Task Completed Checker"; the workflow file that defines the task checker job calls it "task-check":

httomo/.github/workflows/checker_action.yml

Lines 6 to 7 in eb0e5b5

	jobs:
	task-check:

I have no idea where the text "Task Completed Checker" on the RHS is coming from. Unfortunately, I don't think I have permissions to edit the status checks, so I can't check their configuration to see if it's connected to the status checks.

[namannimmo10]

"Task Completed Checker" is coming from https://github.com/kentaro-m/task-completed-checker-action. You need to finish all tasks only then will the CI be green.

[yousefmoazzam]

@namannimmo10 Sure, I understand that a general reference to a task checker is related to that action.

What I'm talking about specifically is this:

• the workflow called "HTTomo tests" is defined in .github/workflows/run_tests_iris.yml
• it has only one job in it, called iris-gpu, and no other jobs
• why does a "HTTomo tests" workflow run (like this one) show the task checker job (which is part of a totally different workflow file, .github/workflows/checker_action.yml) as being part of the "HTTomo tests" workflow

My point is that the following text in the status checks:

HTTomo tests / Task Completed Checker (pull_request)

implies that the task checker job is part of the "HTTomo tests" workflow. But, as far as I can tell, the IRIS tests job and the task checker job are in separate workflows.

After having more time to think about it, this could be related to the fact that the task checker action is triggered by events involving editing the PR - maybe when the PR is edited, the task checker job for whatever reason gets "associated with" some other workflow that already ran (ie, the "HTTomo tests" workflow in this case), even though the task checker is technically part of a different workflow.

In any case, the seeming association of the task checker job with the IRIS workflow file here is the thing that's confusing me 😅

[yousefmoazzam]

Looking at the branch protection settings which is enforcing the status checks, when I search for "task" in the available actions, it displays both "task-check" and "Task Completed Checker"

From what I can tell, what should be available there is all the jobs from all workflow files in the github repo. I understand where the task-check job comes from, it comes from .github/workflows/checker_action.yml:

httomo/.github/workflows/checker_action.yml

Lines 6 to 7 in a94eff8

	jobs:
	task-check:

But where does the "Task Completed Checker" job come from, we have no workflow file that defines this job?

[yousefmoazzam]

If I look at the documentation of the task checker action, it has screenshots which also show a duplicated job https://github.com/marketplace/actions/task-completed-checker#check-whether-tasks-are-completed

Ie, it shows two status checks associated with that action being run:

PR Tasks Check / task-completed-check
PR Tasks Check / Task Completed Checker

and the second one looks like the duplicated job titled "Task Completed Checker" that I've noted previously.

So, it would appear that the action and/or status checks are not incorrectly configured on our end, and the duplicated job for the task checker action is supposed to be there, for whatever reason...

Possibly this is related to the node16 warning for that job (total guess on my part, I saw that when switching the black linting action to get rid of the node16 warning, the duplicated black linting job also went away).

Given that it looks like we're correctly configuring actions + required status checks for the branch protection rule on our end (black linting now has no duplicated job anymore), I think I'm ready to stop harking on about this and blame the task checker action for the duplicated job 🤣