AFAICS, there is nothing in the Pungi compose metadata which explicitly identifies a compose as being from Rawhide. You can hack up this identification by looking for the string 'rawhide' in the location, but this is clearly a hack.

We (QA) definitely need to know when we're dealing with a Rawhide compose. The openQA tests, for instance, need to test installing from a remote repository; when we're installing a Rawhide snapshot compose we need to use a Rawhide repository. For Branched and stable releases we construct the repo URL by parsing the release number out of compose_id, but if you try that with Rawhide you get an invalid URL.

fedfind (which the openQA scheduler used for identifying composes before pungi4) treated 'Rawhide' as a valid 'release' value, and did not synthesize a release number for Rawhide snapshot composes; to fedfind, a Rawhide nightly's version is 'Rawhide (date)', not '24 (date)' as it is for pungi4. I would argue that this is the correct approach; if you really follow through the Fedora release process, Rawhide is itself a release just like any branched release, it's a perpetually rolling release that always exists. Before the 'branch point' for any given release number, that release cannot sensibly be said to exist. You can't say that Rawhide 'is' Fedora 24 right now. It isn't. It's Fedora Rawhide. Fedora 24 will only exist when we branch it. So I would argue that the most-correct way to fix this would be to treat 'Rawhide' as a valid release in Pungi. dgilmore tells me he broadly agrees with this, but it might be difficult to fix, so I'd settle for some other cue in the metadata in the mean time.