Can you explain what this will be used for? Will this cover Pagure/Github/other services? Will this need the extra input data support in libtaskotron to be useful? Are you going to replace dist_git_commit with this in the future?

I think the new type should be added also to ReportType enum in libtaskotron/check.py? I don't remember how much is it needed though.

In D1119#20851, @kparal wrote:

Can you explain what this will be used for? Will this cover Pagure/Github/other services?

Will be used wherever we want to consume raw git commit. If github starts posting fedmessages, we sure can add a consumer, and it would make sense to just have 'git_commit' type there. Currently, it's Pagure.

Will this need the extra input data support in libtaskotron to be useful?

No, why should it? dist_git_commit also does not need it. It will be nicer, once we are able to do it, for sure, but that's about it.

Are you going to replace dist_git_commit with this in the future?

Not now, and can not speak of the future. Might make sense, may not. It is not the time to decide.

In D1119#20853, @mkrizek wrote:

I think the new type should be added also to ReportType enum in libtaskotron/check.py? I don't remember how much is it needed though.

Not honestly sure what the ReportType was/is for but it only covers about half the allowed types anyway. So, while I can add it, I don't see a reason to do it. Do you?

In D1119#20855, @jskladan wrote:

Will this need the extra input data support in libtaskotron to be useful?

No, why should it?

So how will the item look like?

I think the new type should be added also to ReportType enum in libtaskotron/check.py? I don't remember how much is it needed though.

Not honestly sure what the ReportType was/is for but it only covers about half the allowed types anyway. So, while I can add it, I don't see a reason to do it. Do you?

The documentation says:

:ivar str report_type: a definition of the type of the object being checked;
                       for example 'a Koji build', 'a Bodhi update' or 'a
                       yum repository name'. The allowed values are
                       attributes in :class:`ReportType`. You don't have to
                       fill this in (or you can provide a custom string
                       value), but the reporting directives react only to
                       the known types (you can always find it in ResultsDB,
                       though).

But it seems this is some forgotten piece of code, because I don't see the report_type values checked against ReportType anywhere. So the he reporting directives react only to the known types information is probably wrong. Also, we should consolidate _ITEM_TYPES and ReportType structure to have just a single one. Anyone thinks otherwise?

In D1119#20856, @kparal wrote:

So how will the item look like?

Similarly as in the dist_git_commit, it will be a composed value. See D1110 for more details. Relevant line of code:

item = "%s/%s#%s#%s" % (server, repo, branch, end_commit)

Not honestly sure what the ReportType was/is for but it only covers about half the allowed types anyway. So, while I can add it, I don't see a reason to do it. Do you?

The documentation says:

:ivar str report_type: a definition of the type of the object being checked;
                       for example 'a Koji build', 'a Bodhi update' or 'a
                       yum repository name'. The allowed values are
                       attributes in :class:`ReportType`. You don't have to
                       fill this in (or you can provide a custom string
                       value), but the reporting directives react only to
                       the known types (you can always find it in ResultsDB,
                       though).

But it seems this is some forgotten piece of code, because I don't see the report_type values checked against ReportType anywhere. So the he reporting directives react only to the known types information is probably wrong. Also, we should consolidate _ITEM_TYPES and ReportType structure to have just a single one. Anyone thinks otherwise?

Honestly, I'd just get rid of the ReportType completely, but this is not in the scope of this Diff. Let's create a ticket for that, and discuss. For this specific diff, I don't see a reason to add git_commit to ReportType as it is incomplete as it is, and does not seem to be used anyway.