We probably need the combo of commit hash + branch as a commit can belong to multiple branches and a test can pass in say rawhide and fail in say f26.

@pingou Bodhi doesn't currently know the branch name that the commit came from, and I don't recall Koji having that information when I wrote the commit hash code for Bodhi (I could be misremembering). We also cannot assume the release maps to the branch name since modularity is introducing arbitrary branch names. Do you know a way for Bodhi to know the branch name for it's builds?

I do not know how this will look like once the arbitrary branching will be integrated, one way we can do now is to provide the fedora version the update concerns.

I'll ask the folks from the CI pipeline what their plans are for arbitrary branching.

@pingou Using the fedora name for the branch name might be a problem, unless the CI pipeline is only going to test RPMs (and RPMs are going to still have release branches)? If the CI pipeline does test modules that will be a problem because Bodhi does have module support now (and will soon be able to mash them - there's a PR open right now for that).

@bowlofeggs The CI pipeline starts with building the rpm and then test it so it knows in which Fedora version it is building and testing against.

Regarding modules, isn't a module targeted for a certain Fedora version?

@pingou I think a module is still targeted at a specific Fedora version, but I'm not sure how the module build service determines which Fedora it's for (since the branch name will be arbitrary). I think Bodhi may be able to know the Fedora version by inspecting a build's Koji tags. However, knowing the Fedora version in Bodhi doesn't necessarily make it easy to find out what branch the build came from.

@pingou I think a module is still targeted at a specific Fedora version, but I'm not sure how the module build service determines which Fedora it's for (since the branch name will be arbitrary).

I have just been asking this question to @mprahl and the answer was that it will likely be based on a field in the modulemd file (though how this field will look is still being investigated).

However, knowing the Fedora version in Bodhi doesn't necessarily make it easy to find out what branch the build came from.

Clearly not, especially with arbitrary branching which is why I think we should rely on commit hash + Fedora version, these are the only two things we know for sure

Clearly not, especially with arbitrary branching which is why I think we should rely on commit hash + Fedora version, these are the only two things we know for sure

I agree - if those two things are enough information than I think we can proceed. Just note that it's not actually the branch name that CI should report on - it's the Fedora version. With modularity, that difference will be important.

Just note that it's not actually the branch name that CI should report on - it's the Fedora version.

I have started this discussion with @alivigni and the CI team, will keep you posted.

Btw, @tflink this discussion may also interest you as it impacts the way GW will be asking information about CI results to the ci.centos' instance of resultsdb :)

I am blocked on proceeding with the Bodhi integration code until the API for getting test results by commit hash and release is documented.

If we could have the CI CentOS results stored in ResultsDB with commit hash + branch as a unique identifier, and then it would be easier for Greenwave to query the test results. However, I've had a quick chat with Dan, in his opinion, using commit hash is a crazy idea. We'll have a chat with Ralph next week and see if we can come out a better solution.

"Crazy idea" is a bit harsh, I wouldn't say that. :-)

What I'm worried about is: when we query ResultsDB for "type": "koji_build", "item": "a-1.2-3" we are getting back the test results about that specific build in Koji, which is the exact same build in the update that will eventually be shipped to users.

But if the CentOS CI system is doing its own separate build of the package, and then running tests against that -- it means the thing that was tested is not really the same as the thing Bodhi will ship in the update.

And it's not just theoretical... I assume the CentOS CI system is going to be doing scratch builds in Fedora Koji? Not just some local mock configuration or something. But even if it is using the same build target in the same Koji instance, the contents of the build root can still change at any time. If the CI system tested a scratch build done yesterday, but Bodhi is shipping a build that was done today, there could have been changes in the build root which could drastically affect the build output.

So even if we do have a way to map a Koji build back to its dist-git commit hash (I guess we are expecting Bodhi to do this by calling into Koji to look up the build task info?) how can we be sure that any results for that hash are actually still valid?

we are getting back the test results about that specific build in Koji, which is the exact same build in the update that will eventually be shipped to users.

This is something the CI folks are aware of and we're working on reconciling this there are a couple of ways we can do this:
- have the CI pipeline do the builds in koji directly, this would solve all the concerns. I requires some changes to koji itself (such as removing the NVR uniqueness constraint and the possibility to "promote" builds) but upstream koji is aware of them and has agreed to help with this.
- another approach would be to have the CI pipeline register the builds in koji via the content generator interface. This has few drawbacks, including that if the user started a build in koji when the CI pipeline was still running, the CI pipeline won't be able to register its build and we're back to square one. Of course a solution for this would be that users no longer interact with koji and
everything is automated, but this has other implications.

So this is something we are aware of and are working on.

Finally regarding:

how can we be sure that any results for that hash are actually still valid?

I would say that this is a valid question but not really something that GW itself should worry about, from GW's point of view, I'd think it's "garbage in, garbage out", which is valid regardless of the test system running.

We have listed the different options to interact with koji for CI in: https://fedoraproject.org/wiki/FedoraAtomicCI/KojiBuilds

If we could have the CI CentOS results stored in ResultsDB with commit hash + branch as a unique identifier, and then it would be easier for Greenwave to query the test results.

Note that Bodhi doesn't know the branch. It does know the commit hash, and it knows what Koji tags a build has (and thus, what release it is for). So we would need to be able to ask Greenwave for info about builds based on hash and koji tags (or things derived from koji tags, like release).

Alright, so I think this issue is now dependent on how the CI pipeline will report the results onto ResultsDB. And then we can look at what Greenwave should do.

I think this issue is now dependent on how the CI pipeline will report the results onto ResultsDB

Let's invert the question, what would be the best way for greenwave to access the information in resultsdb?
My guess is: commit hash + fedora version tested, is this correct? How should the data be structured?

@tflink maybe you could also shim in here and described how you've approached it so far?

Just to reiterate: I am blocked on finishing the Bodhi Greenwave integration pull request until the Greenwave API around commit hashes and release versions is at least documented (ideally, it would also be implemented, but I can live with documentation as long as it's guaranteed not to change significantly).

Thus, I believe we will need to be able to ask about builds by commit hash from the Greenwave API, in addition to being able to ask about NVR (for the Taskotron results).

Putting debates about how to properly identify content aside for a moment... I believe you can already do this today.

If a result is put into resultsdb with some kind of commit hash string for the item, then you can query greenwave with that same commit hash string in the list of subjects and you should get answers back.

Alright, so I think this issue is now dependent on how the CI pipeline will report the results onto ResultsDB. And then we can look at what greenwave should do.

I think I agree with @mjia here. Today, greenwave accesses results from resultsdb using the only field we've ever talked about -- the item field. If centos ci puts certain strings (hashes? whatever..) in the item field, then bodhi can access them through greenwave using the subjects list field.

It only becomes a greenwave issue if bodhi needs to access results using tuples of identifiers.. but that's new territory for everyone. item seems sufficient.

Let's invert the question, what would be the best way for greenwave to access the information in resultsdb?

I think the answer here is the item field in resultsdb... which doesn't have to be an nvr.

My guess is: commit hash + fedora version tested, is this correct? How should the data be structured?

Just use the item field, like everything else. See also other results already in resultsdb with non-nvr item values as well as one or two demos on that stuff for precedent.

... alllll that said, @dcallagh's concerns are correct. It looks like @pingou's group is addressing them.

@bowlofeggs is the answer above sufficient? Can we close this?

I think this issue is now dependent on how the CI pipeline will report the results onto ResultsDB

Let's invert the question, what would be the best way for greenwave to access the information in resultsdb?
My guess is: commit hash + fedora version tested, is this correct? How should the data be structured?
@tflink maybe you could also shim in here and described how you've approached it so far?

Well, "item" is something that Taskotron uses as a human-readable identifier - it doesn't have to be unique and it's not required for resultsdb. I'm unclear on why this is needed for the bits coming out of the atomic host CI pipeline.

The approach I'm taking is to just store the data coming out of the CI fedmsgs in a way that they can be queried data member by datamember. In short, you'll be able to query based on any of the things listed in the CI docs and get a set of results which can be sorted by time received etc.

Does this help answer some of the question around how to find results?

Can we close this?

@ralph we've been discussing quite a bit how we'll store the data in resultsdb for GW to retrieve but not much how bodhi will interact with GW to get its conclusion based on this new input type (commit hash + fedora release) which I think was the main target of this ticket :)

So, not yet ;-)

@ralph if I can get documentation on what queries Bodhi can make to find out test results for a build by commit hash and Fedora release, that will give me enough information to proceed.

Well, "item" is something that Taskotron uses as a human-readable identifier - it doesn't have to be unique and it's not required for resultsdb. I'm unclear on why this is needed for the bits coming out of the atomic host CI pipeline.
The approach I'm taking is to just store the data coming out of the CI fedmsgs in a way that they can be queried data member by datamember. In short, you'll be able to query based on any of the things listed in the CI docs and get a set of results which can be sorted by time received etc.
Does this help answer some of the question around how to find results?

Storing the commit hash + fedora version into 'item' would make GW easier to find the CI test results . Otherwise, GW would need to expand the subjects list fields to support tuples of identifiers. This also seems working for me. I imagine Bohdi would query Greenwave with [('', ''] as the subject list and then Greenwave will be able to query ResultsDB with the same commit hash + fedora version in the list to make a decision.

So now the question is do we need to expand the subject list field to accept tuples of identifiers?

I think the other thing we might have forgotten to account for in the API is type. I think we have always been assuming that the subject of a test is identified by item + type, for example {"type": "koji_build", "item": "xscreensaver-5.37-3.fc27"}. And internally we have (or will soon have) results for Koji scratch builds like {"type": "koji_scratch_build", "item": "123123"} where the item is the scratch build task ID in Koji. And we have imagined having other types too.

In Greenwave right now we just gloss over the type entirely which is probably a mistake. We are assuming it's always "koji_build" but that's not necessarily true.

And @tflink 's comment indicates that for the CentOS CI results there is no item key at all. Which actually means we might have been operating under a misunderstanding of the meaning of that key...

But so it seems like we probably need to adjust Greenwave's API so that the subject of a decision is a list of dicts, where each one contains the necessary key-values to identify the thing we want to identify. So subjects could be:

{"type": "koji_build", "item": "xscreensaver-5.37-3.fc27"}

or:

{"type": "koji_scratch_build", "item": "123123"}

although I can't think of any reason we would want to have Greenwave looking at scratch build results.

Or for the CentOS CI results, if I'm reading the docs right, something like:

{"rev": "81e09b9c83e8550b54a64c7bdb4e5d7b534df058",
 "repo": "rpms/simplepie",
 "branch": "f24"}

Greenwave would just be looking up results by passing on these key-values directly to the ResultsDB query.

Side note

"branch": "f24"}

Let's try not to stick with the "branch" keyword as this is going to no longer reflect the Fedora version anymore soon :)

we probably need to adjust Greenwave's API so that the subject of a decision is a list of dicts, where each one contains the necessary key-values to identify the thing we want to identify.

:+1: from me.

Okay, I will work out a patch to adjust the API as Dan suggested.

PR #45 .

@bowlofeggs, for Bodhi, I think you can use the following query to ask GW to make a decision based on the CentOS CI results when the approach mentioned by @tflink above has been implemented in ResultsDB.

http post http://0.0.0.0:5005/api/v1.0/decision decision_context="bodhi_update_push_stable" product_version="fedora-26" subject:='[{"commit-hash": "81e09b9c83e8550b54a64c7bdb4e5d7b534df05", "fedora-version": "f26"}]'

Note: I assume ResultsDB will store the commit hash + fedora version like this. The name of these keys in the above example might be changed though.

Does this look good to you?

If we use the name "fedora-version", that might be kind of weird for EPEL.

I guess we should discuss this with the CI team. As I understand, it could be a new key or something used to replace the 'branch' key.

In order to finish https://github.com/fedora-infra/bodhi/pull/1733 I am going to need a hard answer on exactly what query Bodhi should make to Greenwave when asking about an update. Keep in mind that it's not just CI that matters here, but also regular ResultsDB entries. That means that we need to ask about commit hashes, NVRs, and I think the update ID itself as well (not 100% sure on that one). I'll need to know the precise syntax for each of these entries.

So, say I have an update with foo-2.0.1-3.fc26 and bar-5.10.1-1.fc26 that have commit hashes of abcde and 12345 respectively, and they are in an update named FEDORA-2017-abc123. What exact query should Bodhi make to Greenwave about this example update?

So, say I have an update with foo-2.0.1-3.fc26 and bar-5.10.1-1.fc26 that have
commit hashes of abcde and 12345 respectively, and they are in an update named
FEDORA-2017-abc123. What exact query should Bodhi make to Greenwave about this
example update?

Try this.

data = {
    # This can be epel-7 or epel-6 also, see https://pdc.fedoraproject.org/rest_api/v1/product-versions/
    'product_version': 'fedora-26',
    'decision_context': 'bodhi_push_update_stable',
    'subjects': [
        # I'm sure about these two
        {'item': 'foo-2.0.1-3.fc26', 'type': 'koji_build'},
        {'item': 'bar-5.10.1-1.fc26', 'type': 'koji_build'},
        # I'm also sure about this one.
        {'item': 'FEDORA-2017-abc123', 'type': 'bodhi_update'},
        # I'm unsure about this one.  Consult the "CI" docs, or ping pingou or tflink
        {'rev': 'abcde', 'repo': 'rpms/foo', 'branch': 'f26'},
        {'rev': '12345', 'repo': 'rpms/bar', 'branch': 'f26'},
    ],
}
util.greenwave_api_post(greenwave_url, data)

Where can I find the CI docs? Also, as discussed earlier in this ticket, Bodhi does not know the branch that a commit came from. Bodhi only knows the scm URL, which looks like this:

git://pkgs.fedoraproject.org/rpms/bodhi?#05875798da4fac53c0b93549862cec1d713f1c46

So we can't use branch, since modularity will introduce arbitrary branch names.

So we can't use branch, since modularity will introduce arbitrary branch names.

For the moment we will have to rely on this since it is all we've got :(

Isn't a proposal to use modules for the atomic release that this CI effort is for? If that proposal is accpeted, then this plan won't work even in the short term. And even if that isn't the plan for CI, introducing modular builds is the plan for F27, so Bodhi is going to be querying about them and their branch names aren't going to be things like "f27".

I don't have an answer for you on this.

Maybe @stefw or @arilivigny would?

@bowlofeggs I imagine that we'll get to a point where commit hashes are also no longer unique as far as commit results. Do you need a unique ID?

For the record, GitHub uses the following logic to display results:

• Use the commit id as a lookup identifier
  • Our analog: Use either the NVR or commit hash as our lookup identifier.
• Lookup all the "statuses" for that identifier.
  • Our analog: These are our greenwave entries.
• Each status has a "context" the type of result being composed
  • Our analog: Our contexts may be Phoebe test vs. rpm.diff vs. rpm.lint results
• Display and gate on the latest (by date) "status" for each "context". Ignore any earlier status.

There is no unique lookup identifier in this system. The various results have an arbitrary unique identifier in GitHub but it is useless for any sort of lookup.

Keep in mind that at some point we will need to retrigger test runs for a given identifier.

Neither the NVR or commit hash will be unique: This is a reality in almost any real world CI systems. A package maintainer should be able to ask for the test to be run again (see Travis, Semaphore, Ubuntu CI, Openshift CI, Cockpit CI).

Am I misunderstanding something fundamental here? If so it's probably worth further discussion and I'd be happy to help. Lastly, if we do need additional fields from the pipeline I can also help here, both with code and working details out with people.

Hi @stefw, thanks for the thoughtful reply!

Bodhi doesn't necessarily need the lookup identifier to be unique as long as Greenwave is able to deal with the identifier not being unique. As I understand it, Greenwave doesn't mind if there are multiple test runs for the same commit hash or NVR, and it has ways to handle the maintainer asking for a test to be run again.

What Bodhi does need is the exact query it will use to ask Greenwave for a yes/no decision on gating an update. I had been told on and off that Bodhi will need to include the branch name in its query to Greenwave along with the commit hash, and that is the bit that I'm worried about since Bodhi doesn't have a mechanism to know which branch name a build came from. Bodhi does have a mechanism to know the repository name and commit hash, just not the branch name. Can Bodhi just ask Greenwave for a decision with the commit hash, leaving off the branch name? If not there might be a problem to solve, and if so I just need to know the exact API call that Bodhi will make to do that.

Oh, and Bodhi does also know a release that a Build is part of currently. It may seem tempting to use the release to guess the branch name, but with modularity that is no longer possible (hence my questions ☺). But if the release can be useful for looking results up outside of the branch name, then Bodhi knows that too.

I had a good chat with @stefw and @tflink in #fedora-ci today. It sounds like I can query with the keys "ref", "namespace", and "repo" to get test results (i.e., I shouldn't need branch name). They gave me an example resultsdb result:

http://resultsdb.ci.centos.org/resultsdb/results/1494

Thus, I believe this would be the correct syntax for my example above:

data = {
    # This can be epel-7 or epel-6 also, see https://pdc.fedoraproject.org/rest_api/v1/product-versions/
    'product_version': 'fedora-26',
    'decision_context': 'bodhi_push_update_stable',
    'subjects': [
        # I'm sure about these two
        {'item': 'foo-2.0.1-3.fc26', 'type': 'koji_build'},
        {'item': 'bar-5.10.1-1.fc26', 'type': 'koji_build'},
        # I'm also sure about this one.
        {'item': 'FEDORA-2017-abc123', 'type': 'bodhi_update'},
        # I'm unsure about this one.  Consult the "CI" docs, or ping pingou or tflink
        {'rev': 'abcde', 'repo': 'foo', 'namespace': 'rpms'},
        {'rev': '12345', 'repo': 'bar', 'namespace': 'rpms'},
    ],
}
util.greenwave_api_post(greenwave_url, data)

Could someone from the Greenwave side +1/-1 the above?

Here is the full conversation for the record:

<pingou> stefw: https://pagure.io/greenwave/issue/34#comment-455995 could use your input
<pingou> and if the fedmsg structure is going to change, that needs to be announced before
* tyll has quit (Read error: Connection reset by peer)
* tyll (~till@fedora/tyll) has joined
* Sir_Gallantmon is now known as Son_Goku
<stefw> pingou, answered there
<stefw> i hope i understood the problem
<stefw> if so, it's a problem that GitHub and pretty much every other CI system has faced
<stefw> ie: "GitHub" as a way of recording test results and/or gating on them
<stefw> bowlofeggs, FYI ^^
* Son_Goku has quit (Ping timeout: 255 seconds)
<bowlofeggs> stefw: i replied - the problem i'm facing is actually simpler than that problem i hope - i just need to know a query i can make against greenwave to get a yes/no on a set of builds, ideally without having to know a branch name
<bowlofeggs> stefw: the problem is that bodhi doesn't know branch names from CI, and i don't know an immediately obvious way to find them out
<bowlofeggs> stefw: but bodhi does know the commit has
<bowlofeggs> h
<stefw> and it does know the release name
<bowlofeggs> stefw: and it also knows the release, but that can't be used to guess a branch name because of modularity
<bowlofeggs> starting in f27, the branch name no longer has a relationship with the release
<stefw> until bodhi learns about modules ... 
<stefw> will bodhi need to learn about modules at that point?
<bowlofeggs> well bodhi does know about modules already, but it does not introspect them
<stefw> said another way ... will bodhi need to receive or determine branch information in order to deal with arbitrary branching in fedora 27?
<bowlofeggs> bodhi's actually very close to being able to ship modules
<bowlofeggs> stefw: i do not believe so
<stefw> does a bodhi update related to a module know about a release?
<stefw> does it target a release?
<bowlofeggs> stefw: commit hashes should be unique in git though - can we just query with the commit hash and leave the branch name off?
<stefw> i think so
<stefw> although more strictly speaking
<bowlofeggs> stefw: it will target a release, and the release will be determined by koji tags (which is how it works for rpms today)
<stefw> the combination of: repo + commit hash ... is a better identifier
<bowlofeggs> stefw: bodhi does know the repo name too, so that'll work
<stefw> keep in mind that in the future there will be multiple tests results per such identifier
<bowlofeggs> stefw: as long as greenwave is ok with that, bodhi will be fine too
<stefw> even in the simple case of repeated tests ... but i already described that in detail
<stefw> bowlofeggs, yes, you're right to put that problem on greenwave ++
<stefw> s/put/punt/
<bowlofeggs> stefw: bodhi doesn't necessarily need to know about all the test results, it just needs a way to ask greenwave for a yes/no based on information it does have, and it doesn't have a branch name ☺
<stefw> so can you query greenwave based on repo + commitid today?
<stefw> or does that require changes to greenwave?
<bowlofeggs> stefw: yes i can do that
<stefw> perfect
<bowlofeggs> stefw: i don't know about greenwave
<stefw> pingou, do you know? ^^
<bowlofeggs> but what i mean is taht bodhi does know that info (repo name + commit hash)
<stefw> roger
<stefw> threebean, do you know if bodhi can query greenwave asking for test results for an identifier like: (dist-git repo + commitid)
<bowlofeggs> so if we can proceed with those two, and if greenwave can find what it needs in resultsdb with those two, i think we don't have a problem to solve other than i need greenwave API syntax ☺
<bowlofeggs> i think the greenwave people themselves might not know the answer because it might depend on how the info is stored in resultsdb
<bowlofeggs> so, can you store the info in resultsdb by repo name + commit hash? if so, i think greenwave and bodhi will be able to get things to work
<tflink> afaik, you can
* tflink double checks
<bowlofeggs> tflink: or i guess even more precisely, my question is: "can greenwave use only repo name and commit hash to look up results from resultsdb"
<bowlofeggs> i guess storing the branch name obviously won't hurt anything, so long as i don't need to know it to look up results
<tflink> http://resultsdb.ci.centos.org/resultsdb/results/1494
<tflink> is an example of the data stored
<tflink> eh, that's a compose
<tflink> a build is http://resultsdb.ci.centos.org/resultsdb/results/1480
<tflink> I see repo and rev
<bowlofeggs> tflink: oh, so could i do a query for {'ref': 'whatever', 'namespace': 'rpms', 'repo': 'bodhi'}?
<stefw> cool, so the info is there ... but can any field (or specifically 'repo' and 'rev') be used in a query via greenwave?
* stefw has a collision with bowlofeggs
<bowlofeggs> haha
<bowlofeggs> jinx! now you owe me a coke at flock
<bowlofeggs> but i don't drink coke
<stefw> flock will involve bartering i'm sure :D
<bowlofeggs> ☺
<tflink> that's the idea, yes
<bowlofeggs> excellent
* tflink tries to get an example URI
<bowlofeggs> i think that gives me enough info to proceed!

As a side note, there's a bug in the ci listener code which is populating results with data that can't be queried. It's a simple fix and I'll coordinate with pingou to get the fix in and deployed

https://pagure.io/ci-resultsdb-listener/issue/2

Thanks for the heads up @tflink!

LGTM. Bear in mind, if there are multiple results per "ref"+ "namespace"+"repo", Greenwave will take the latest one into account and ignore the others. BTW, does Bodhi know "namespace" or in this case it is just a static value "rpms"?

@mjia I think that would be the correct behavior (taking the latest results and ignoring the others). I think Bodhi's web UI also works that way. Bodhi does know the namespace, so it will be able to provide that info in the query.

Ok now that I know the query I will make against Greenwave, I will close this issue. Thanks for all the help everyone!

I came to the conclusion today that Bodhi cannot know the commit hash reliably. Here's a wall-o-text I wrote into #fedora-ci:

<bowlofeggs> it just occurred to me that the scm_url in koji is not guaranteed to know a commit hash
<bowlofeggs> when users use "fedpkg build" to make a build in koji, it will have a commit hash
<bowlofeggs> but! users can say "koji build f26 git://whatever/#master"
<bowlofeggs> i know that works because i do it sometimes
<bowlofeggs> and when users do that, bodhi will not be able to figure out what commit hash it was
<bowlofeggs> because bodhi is really just asking koji for the scm url that was used to make the build, not what commit was used
<bowlofeggs> and i don't think koji does record the commit hash when it isn't part of the scm_url
<bowlofeggs> you can even leave off the #master and just say "koji build f26 git://whatever/rpms/package" and head will be used
<bowlofeggs> technically, koji admin users can also make builds from srpms, so that would work even worse, but i think this commit hash thing is a realistic problem
<bowlofeggs> this makes me think that we really might need to store the results in resultsdb by nvr
<bowlofeggs> or, we need a formal way for koji to store the commit hash that a build came from
<bowlofeggs> pingou, stefw: ^
<bowlofeggs> there's another potential problem - will every commit be built and tested in the CI pipeline, or only the head of every push (which is what things like jenkins tend to do)?
<bowlofeggs> because things like merge commits might cause bodhi to see a commit hash on an nvr that never got tested in the CI pipeline
<bowlofeggs> i think this might require us to get the results reported as NVR for bodhi
<bowlofeggs> also, this same info reveals that the scm url is not unique, so it was wrong of bodhi to put a uniqueness constraint on it
<bowlofeggs> i could have ten very different nvrs that were all built with git://pkgs.fedoraproject.org/rpms/bodhi?#master
<bowlofeggs> so we also can't use scm_url to match tests to builds

I have filed https://github.com/fedora-infra/bodhi/issues/1738 about dropping the scm_url field from Bodhi since it no longer seems useful.

We had a discussion today with the CI pipeline folks, and we agreed that they will post results into Fedora's ResultsDB instance by NVR instead of by commit hash. Thus, I plan to make the following example query to Greenwave:

data = {
    # This can be epel-7 or epel-6 also, see https://pdc.fedoraproject.org/rest_api/v1/product-versions/
    'product_version': 'fedora-26',
    'decision_context': 'bodhi_push_update_stable',
    'subjects': [
        {'item': 'foo-2.0.1-3.fc26', 'type': 'koji_build'},
        {'item': 'bar-5.10.1-1.fc26', 'type': 'koji_build'},
        {'item': 'FEDORA-2017-abc123', 'type': 'bodhi_update'},
    ],
}
util.greenwave_api_post(greenwave_url, data)

The query looks good to me. It seems to me we need to expand the policy [1] to cover epel-6 and epel7.

[1] https://pagure.io/greenwave/blob/master/f/conf/policies/fedora.yaml