That sounds good to me.

To be more precise, critpath contains 1922 list of packages. So, right now we are already running on pretty good sub-set of packages :)

! In #823#11613, @sinnykumari wrote:
To be more precise, critpath contains 1922 list of packages. So, right now we are already running on pretty good sub-set of packages :)

I had a look at it and lists all releases. If you look at just one branch, it's much shorter (400 packages):
https://admin.fedoraproject.org/pkgdb/api/critpath?branches=f24

! In #823#11625, @kparal wrote:

! In #823#11613, @sinnykumari wrote:
To be more precise, critpath contains 1922 list of packages. So, right now we are already running on pretty good sub-set of packages :)

I had a look at it and lists all releases. If you look at just one branch, it's much shorter (400 packages):
https://admin.fedoraproject.org/pkgdb/api/critpath?branches=f24

Hmm, I didn't know that there is a separate list of critpath packages for each Fedora branch. I was only aware of https://admin.fedoraproject.org/pkgdb/api/critpath and thought that this is what get referred in all branch.

Yeah, it seems it is per branch. Also, json format is much more obvious:
https://admin.fedoraproject.org/pkgdb/api/critpath?format=json

! In #823#11628, @kparal wrote:
Yeah, it seems it is per branch. Also, json format is much more obvious:
https://admin.fedoraproject.org/pkgdb/api/critpath?format=json

Thanks, this link is indeed useful to get better picture of what is included in critpath list per branch.

@sinnykumari asked today again on IRC whether we could do this. @mkrizek, can you adjust the trigger configuration on dev?

@dodji disagreed a bit with this today, saying we should do the opposite - start notifying people about results by default, and gradually expand this to other packages (but not immediately to all of them). Since he can't log in and post a comment here, I asked him to start a discussion on qa-devel list.

@sinnykumari talked to us on DevConf and asked again to extend task-abicheck to all packages. Also, if it works correctly, to talk to Bodhi maintainers and start disabling autokarma if it fails (the same they do for depcheck and upgradepath). I think that's a reasonable approach, because FMN has quite a few rough edges and I think this is an easier approach than what @dodji has suggested.

@mkrizek, could you adjust the trigger on dev and start running abicheck on all packages? Thanks a lot.

! In #823#12715, @kparal wrote:
...
@mkrizek, could you adjust the trigger on dev and start running abicheck on all packages? Thanks a lot.

Done.

Thanks @kparal and @mkrizek for getting quickly enabled abicheck task run on all packages on dev instance :)
I was interested in looking into logs on run made after changes and tried to browse to link https://taskotron-dev.fedoraproject.org/resultsdb/results but got Internal Server error. In case url is changed, please let me know :)
Also, for taskotron production instance when I open link https://taskotron.fedoraproject.org/resultsdb/results?testcases=dist.abicheck to see test results related to abicheck run, front page works fine. But when I click on "Older Results" to see some previous results, it doesn't show me results related to abicheck task rather it shows results related to depcheck task run.

! In #823#12912, @sinnykumari wrote:
I was interested in looking into logs on run made after changes and tried to browse to link https://taskotron-dev.fedoraproject.org/resultsdb/results but got Internal Server error. In case url is changed, please let me know :)

We were just deploying a new version. It's working now.

Also, for taskotron production instance when I open link https://taskotron.fedoraproject.org/resultsdb/results?testcases=dist.abicheck to see test results related to abicheck run, front page works fine. But when I click on "Older Results" to see some previous results, it doesn't show me results related to abicheck task rather it shows results related to depcheck task run.

Yeah, that's a bug. You can manually add &page=1 to see the next page. We want to deploy the fix into production soon.

! In #823#12734, @mkrizek wrote:

! In #823#12715, @kparal wrote:
...
@mkrizek, could you adjust the trigger on dev and start running abicheck on all packages? Thanks a lot.

Done.

Can we also enable abicheck on taskotron dev instance for rawhide package updates too? I see ongoing mass rebuild a good place to get abicheck task run analyzed on more number of packages.

! In #823#12965, @sinnykumari wrote:

! In #823#12734, @mkrizek wrote:

! In #823#12715, @kparal wrote:
...
@mkrizek, could you adjust the trigger on dev and start running abicheck on all packages? Thanks a lot.

Done.

Can we also enable abicheck on taskotron dev instance for rawhide package updates too? I see ongoing mass rebuild a good place to get abicheck task run analyzed on more number of packages.

We already do :) The problem we've been having recently is, though, that we have broken rawhide images so tasks on rawhide builds fail before they are started. Sorry about that. :/

! In #823#12967, @mkrizek wrote:

! In #823#12965, @sinnykumari wrote:

! In #823#12734, @mkrizek wrote:

! In #823#12715, @kparal wrote:
...
@mkrizek, could you adjust the trigger on dev and start running abicheck on all packages? Thanks a lot.

Done.

Can we also enable abicheck on taskotron dev instance for rawhide package updates too? I see ongoing mass rebuild a good place to get abicheck task run analyzed on more number of packages.

We already do :) The problem we've been having recently is, though, that we have broken rawhide images so tasks on rawhide builds fail before they are started. Sorry about that. :/

Ah ok, that explains why I didn't see any recent abicheck run on rawhide packages on dev instance. Thanks for the information :)

Abicheck in Rawhide is broken anyway at the moment, see this ticket.

! In #823#12970, @kparal wrote:
Abicheck in Rawhide is broken anyway at the moment, see this ticket.
I have monitored some of latest abicheck task run on rawhide packages from mass rebuild and it seems to do comparison with previous f26 build available in koji. Some of log links are:

https://taskotron.fedoraproject.org/artifacts/all/f01167ea-f055-11e6-be47-5254008e42f6/task_output/libproxy-0.4.14-2.fc26.log
https://taskotron.fedoraproject.org/artifacts/all/347ebc40-f04a-11e6-b66e-5254008e42f6/task_output/libical-2.0.0-9.fc26.log
https://taskotron.fedoraproject.org/artifacts/all/4a0f86a2-f00e-11e6-b66e-5254008e42f6/task_output/libsmbios-2.3.0-4.fc26.log
https://taskotron.fedoraproject.org/artifacts/all/b883a800-eff7-11e6-b66e-5254008e42f6/task_output/gjs-1.47.4-2.fc26.log
https://taskotron.fedoraproject.org/artifacts/all/6ac9be88-efbb-11e6-be47-5254008e42f6/task_output/enchant-1.6.0-16.fc26.log

One of abicheck run log before mass rebuild:
https://taskotron.fedoraproject.org/artifacts/all/5308fa22-eef1-11e6-91d5-5254008e42f6/task_output/nss-3.29.0-3.fc26.log
Both packages compared has f26 tag

Can it be that some changes has been made while considering rawhide package build update?

Interesting, I have no idea why it should magically work now :)

This has been fixed as part of taskotron#238 .