GitLab job/pipeline don't have conclusion fields

[spencerschrock]

GitHub worksflows have two fields, Status and Conclusion, which is what we built into our model.

GitLab, just has a Status. I think we can parse the status field to set status and conclusion to their GitHub equivalent, or we can adjust the model going forward to be more generic. We may not have an answer immediately.

This seems to affect the CI-Tests and SAST checks.

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[ashearin]

GItlabs Status field seems to be almost a combination of the Conclusion and Status fields in Github. Would it make sense to only pull completed pipelines in listCheckRunsForRef (potentially only for Gitlab) and just set the status to completed? I see that both the sast and ci tests check that the status is 'completed' before further processing.

Not sure if this issue requires more high level discussion, but I'm happy to take a whack at it

[spencerschrock]

I see that both the sast and ci tests check that the status is 'completed' before further processing.

SAST also checks the conclusion:

scorecard/checks/raw/sast.go

Line 45 in 76878e5

var allowedConclusions = map[string]bool{"success": true, "neutral": true}

scorecard/checks/raw/sast.go

Lines 101 to 103 in 76878e5

	if !allowedConclusions[cr.Conclusion] {
	continue
	}

Would it make sense to only pull completed pipelines in listCheckRunsForRef (potentially only for Gitlab) and just set the status to completed?

We generally like to put all data in the raw results, and let the evaluation code handle the judging. Is there a reason to not do this for GitLab?

[ashearin]

We generally like to put all data in the raw results, and let the evaluation code handle the judging. Is there a reason to not do this for GitLab?

No reason, really. My thought was to use calls we're already making to get more info about the pipelines to help decide what goes in the conclusion and status fields for gitlab pipelines. Let me try to explain what I meant a bit better:

• Pull in only completed pipelines when running checks on a gitlab repo,
  • set the status to completed,
  • Set Conclusion to the pulled pipeline status, since we should have the success/fail/skipped in there (DIdn't mention this part initially, obviously want the conclusion field populated)

I get wanting to pull everything and let the code filter through it as needed (we may look at non-completed pipelines at some point). Just wanted to gauge preferences on this before proposing changes. Parsing the GItlab Status and inferring the conclusion and Status fields would also work.