Repository: go-gitea/gitea
File: models/actions/run_job_status_test.go (Go)

Code before:
		{[]Status{StatusUnknown, StatusFailure}, StatusFailure},
		{[]Status{StatusUnknown, StatusCancelled}, StatusCancelled},
		{[]Status{StatusUnknown, StatusWaiting}, StatusWaiting},
		{[]Status{StatusUnknown, StatusRunning}, StatusRunning},
		{[]Status{StatusUnknown, StatusBlocked}, StatusBlocked},

		// success with other status
		{[]Status{StatusSuccess}, StatusSuccess},
		{[]Status{StatusSuccess, StatusSkipped}, StatusSuccess}, // skipped doesn't affect success
		{[]Status{StatusSuccess, StatusFailure}, StatusFailure},
		{[]Status{StatusSuccess, StatusCancelled}, StatusCancelled},
		{[]Status{StatusSuccess, StatusWaiting}, StatusWaiting},
		{[]Status{StatusSuccess, StatusRunning}, StatusRunning},
		{[]Status{StatusSuccess, StatusBlocked}, StatusBlocked},

		// any cancelled, then cancelled
		{[]Status{StatusCancelled}, StatusCancelled},
		{[]Status{StatusCancelled, StatusSuccess}, StatusCancelled},
		{[]Status{StatusCancelled, StatusSkipped}, StatusCancelled},
		{[]Status{StatusCancelled, StatusFailure}, StatusCancelled},
		{[]Status{StatusCancelled, StatusWaiting}, StatusCancelled},
		{[]Status{StatusCancelled, StatusRunning}, StatusCancelled},
		{[]Status{StatusCancelled, StatusBlocked}, StatusCancelled},

		// failure with other status, usually fail fast, but "running" wins to match GitHub's behavior
		// anther reason that we can't make "failure" wins over "running": it would cause a weird behavior that user cannot cancel a workflow or get current running workflows correctly by filter after a job fail.
		{[]Status{StatusFailure}, StatusFailure},
		{[]Status{StatusFailure, StatusSuccess}, StatusFailure},
		{[]Status{StatusFailure, StatusSkipped}, StatusFailure},
		{[]Status{StatusFailure, StatusCancelled}, StatusCancelled},
		{[]Status{StatusFailure, StatusWaiting}, StatusFailure},
		{[]Status{StatusFailure, StatusRunning}, StatusRunning},
		{[]Status{StatusFailure, StatusBlocked}, StatusFailure},

		// skipped with other status
		// "all skipped" is also considered as "mergeable" by "services/actions.toCommitStatus", the same as GitHub
		{[]Status{StatusSkipped}, StatusSkipped},
		{[]Status{StatusSkipped, StatusSuccess}, StatusSuccess},
		{[]Status{StatusSkipped, StatusFailure}, StatusFailure},
		{[]Status{StatusSkipped, StatusCancelled}, StatusCancelled},
		{[]Status{StatusSkipped, StatusWaiting}, StatusWaiting},
		{[]Status{StatusSkipped, StatusRunning}, StatusRunning},
		{[]Status{StatusSkipped, StatusBlocked}, StatusBlocked},
	}

	for _, c := range cases {
		testStatuses(c.expected, c.statuses)
	}
}


Review comment (bug):
```suggestion
		// another reason that we can't make "failure" wins over "running": it would cause a weird behavior that user cannot cancel a workflow or get current running workflows correctly by filter after a job fail.
```

Code after:
		{[]Status{StatusUnknown, StatusFailure}, StatusFailure},
		{[]Status{StatusUnknown, StatusCancelled}, StatusCancelled},
		{[]Status{StatusUnknown, StatusWaiting}, StatusWaiting},
		{[]Status{StatusUnknown, StatusRunning}, StatusRunning},
		{[]Status{StatusUnknown, StatusBlocked}, StatusBlocked},

		// success with other status
		{[]Status{StatusSuccess}, StatusSuccess},
		{[]Status{StatusSuccess, StatusSkipped}, StatusSuccess}, // skipped doesn't affect success
		{[]Status{StatusSuccess, StatusFailure}, StatusFailure},
		{[]Status{StatusSuccess, StatusCancelled}, StatusCancelled},
		{[]Status{StatusSuccess, StatusWaiting}, StatusWaiting},
		{[]Status{StatusSuccess, StatusRunning}, StatusRunning},
		{[]Status{StatusSuccess, StatusBlocked}, StatusBlocked},

		// any cancelled, then cancelled
		{[]Status{StatusCancelled}, StatusCancelled},
		{[]Status{StatusCancelled, StatusSuccess}, StatusCancelled},
		{[]Status{StatusCancelled, StatusSkipped}, StatusCancelled},
		{[]Status{StatusCancelled, StatusFailure}, StatusCancelled},
		{[]Status{StatusCancelled, StatusWaiting}, StatusCancelled},
		{[]Status{StatusCancelled, StatusRunning}, StatusCancelled},
		{[]Status{StatusCancelled, StatusBlocked}, StatusCancelled},

		// failure with other status, usually fail fast, but "running" wins to match GitHub's behavior
		// another reason that we can't make "failure" wins over "running": it would cause a weird behavior that user cannot cancel a workflow or get current running workflows correctly by filter after a job fail.
		{[]Status{StatusFailure}, StatusFailure},
		{[]Status{StatusFailure, StatusSuccess}, StatusFailure},
		{[]Status{StatusFailure, StatusSkipped}, StatusFailure},
		{[]Status{StatusFailure, StatusCancelled}, StatusCancelled},
		{[]Status{StatusFailure, StatusWaiting}, StatusFailure},
		{[]Status{StatusFailure, StatusRunning}, StatusRunning},
		{[]Status{StatusFailure, StatusBlocked}, StatusFailure},

		// skipped with other status
		// "all skipped" is also considered as "mergeable" by "services/actions.toCommitStatus", the same as GitHub
		{[]Status{StatusSkipped}, StatusSkipped},
		{[]Status{StatusSkipped, StatusSuccess}, StatusSuccess},
		{[]Status{StatusSkipped, StatusFailure}, StatusFailure},
		{[]Status{StatusSkipped, StatusCancelled}, StatusCancelled},
		{[]Status{StatusSkipped, StatusWaiting}, StatusWaiting},
		{[]Status{StatusSkipped, StatusRunning}, StatusRunning},
		{[]Status{StatusSkipped, StatusBlocked}, StatusBlocked},
	}

	for _, c := range cases {
		testStatuses(c.expected, c.statuses)
	}
}