#3387 Support notifications from jenkins about builds in progress
Merged by pingou. Opened by pingou.
flag_in_progress  into  master

Download 3387.patch
no initial comment

I would suggest having PENDING and RUNNING states. The former is for when the job is being queued, and the latter is when it is being run.

Obviously, not every CI system that would get wired into Pagure supports all these states, but I believe Jenkins certainly does (as do most newer OSS CI systems, like Drone CI, Concord CI, etc.).

While potentially doable, I think this change is out of scope for this PR as it would imply more changes than what is here.

I don't know about that. The goal here is to have more accurate reporting from Jenkins, and I also don't really want to see FLAG_PENDING being used for BUILDING state.

A quick comparison here: at work, the system we use that I've written custom integrations for has PENDING (color gray) -> RUNNING (color blue) -> (SUCCESS (color green)/FAILURE (color red)/CANCELLED (color black)). Each of these states represents a distinct state so that people know what's going on.

The amount of work is always asymmetric to capacity available in CI, so the PENDING state is useful to indicate a job has been queued up and hasn't started yet, and RUNNING state means the job is in progress.

At least the simplest thing I'd ask is that Pagure doesn't wire BUILDING to FLAG_PENDING.

Oh, and for completions' sake, there's also SKIPPED (color black) and SUCCESS_WARN (color orange) for conditions like jobs considered not valid in this case and warnings occurring even though the job was successful.

You're assuming pending means the tasks is pending while for pagure pending means, the results are pending: https://docs.pagure.org/pagure/usage/flags.html

Again, adding more levels is out of the scope of this PR as it requires more changes than just in this file.

The code is fine, but I think the underlying assumption about the presentation and understanding of the states is probably broken.

That said, this PR can go in, since it does work and the code looks good to me.

the underlying assumption about the presentation and understanding of the states is probably broken.

Should we settle for incomplete? :)

Thanks for the review and the discussion though it is insightful!

Pull-Request has been merged by pingou

Metadata