CC @kparal @msuchy @mkluson @clime

What are the specifics of this user story? Why should copr tell CI systems to run tests instead of just announcing there are new packages available which CI (or even multiple CI's) can pick up and do what is configured/enabled for testing?

I'll let others comment, but from what I remember, some of the reasons were I believe the following:

• You need to build several interconnected packages in your COPR and the tests would fail until all of them are complete. The user could specify that tests should be run just after the whole batch. The system would send "don't test this" flag for each interim build, and send "test this" flag for the last build (or the user would do that manually using a button).
• The ability to re-run tests. If the user fixes a bug in the test suite, he wants to re-execute the test suite. Clicking a button would cause COPR to send "test this COPR" message.
• You can perhaps configure your COPR that some specific package never triggers testing, or that only a specific package triggers it. (I'm not sure about this use case)
• COPR (or any other system) could save some time and effort of the CI system by sending "don't test this" flag when it knows that e.g. there's no test suite for this particular repo (which would otherwise need to be queried by the CI system, which consumes time and resources)
• It allows opt-in or opt-out approach in COPR (or any other system)

We (OSCI) are currently brainstorming about such "test-request" messages, but I share the same point of view as @psss expressed in his comment above. Build systems are not the ones who should decide what and when should be tested. That shouldn't be their concern.

Since this request is currently 11 months old, with no activity for a very long time, is this still something that people would want to explore/move forward?

Even though I summarized the use cases (those which I remembered), I was just a third-party in the meeting. The COPR folks are the major stakeholders here. The use cases I wrote down were things we discussed when thinking about how to perform testing on top of COPRs well. Surely there are other solutions to those issues, the one proposed is the one we came up with. I honestly forgot everything else that hasn't been written already in this ticket.

Note that the COPR people don't seem to be among subscribers in this ticket, because in Pagure you can't subscribe someone with "cc name", just send a one-time notification.
@msuchy @clime @mkluson

Bodhi also needs such a feature as a mechanism to allow re-triggering one or more tests :)

My impression is that proposing this as a request from build system is mixing responsibilities of build systems (build things) and CI systems (test built things).

On the other hand, who am I to judge how far want Copr & its developers extend their reach :) If Copr developers want to enhance it with (even partial) CI system functionality, it's not really my concern. I'd just recommend relaxing the use case, not being specific for "build system". Pretty much any use case of the list is valid for any interested user, not just the build system, given the clearly defined "test requests" API.

And WRT the gist of the issue, currently, we're working on a prototype of "test stuff" , which would be triggered via REST API, not UMB message - we feel it's more fitting the workflow than emitting messages. We have a preliminary API proposal and environment description. In the request, one would describe the artifact (or more) to test, environments to run tests in (including additional repositories and packages to install), what tests to execute.

I believe the build system is mentioned as just one particular user story. Of course the same use case can make sense for other systems as well. Also, it will be often the user submitting the request ("re-run tests" button), just through the interface of the particular build/other system. If you believe the workflow should be different (e.g. you can't re-run tests from koji/copr, but you can go to a special "CI hub" where you can configure everything related to tests, see results, re-run them, etc), sure, that's also a solution. But you'll still likely need the same plumbing, just executed from elsewhere. And some of the use cases (like executing the tests only after the whole batch of dependent packages has been completed) is probably something that only the source system (like koji/copr/bodhi) can decide properly.

CI testing for Copr never happend and seems it will not in a forseable futrue.

@msrb from OSCI side, 9months later, does it still stand we need this? :)