@mohanboddu @bowlofeggs ,

Regarding koji tag we could go with fXX-container-update-candidate and fXX-container-update.

Once a container would be built it would then be tagged fXX-container-update-candidate in koji. Bodhi would use this tag to look for update candidate.

If an update was created for this container, during the daily push bodhi will apply the container tag testing and the build will then be tagged in koji with fXX-container-update.

Once enough karma was given or once X days were passed bodhi will move the container tag testing to latest.

Can you both +1 if the above looks sane to you. If so then @mohanboddu could you create the container release in bodhi stg for f28 and create the needed tag in koji.

Thanks

@cverna Now I think about it, its better to add fXX-container-updates-testing as well, since that way we know how many are in testing and how long they have been there and other sort of things.

So, once the container is built it will tagged into fXX-container-updates-candidate and once the build is pushed in bodhi then it will be tagged as fXX-container-updates-testing and gets untagged from fXX-container-updates-candidate in koji and tagged as testing in the registry.

Once enough karma was given or once X days were passed bodhi will move the container tag testing to latest and tag the build with fXX-container-updates tag and gets untagged from fXX-container-updates-testing.

@bowlofeggs Not sure if this requires -pending tags, if you need them please let me know.

I think Bodhi will expect containers to have all the same kinds of tags that RPMs have. So let's just reuse all the same tags that f28 has, but s/f28/f28-container on each of them.

Created the necessary tags in stg koji. I haven't created any tags related to signing, since we are far away from that feature and dont know if stg will ever get that feature.

$stg-koji add-tag --parent f28-container f28-container-updates
$stg-koji add-tag --parent f28-container-updates f28-container-updates-candidate
$stg-koji add-tag --parent f28-container-updates f28-container-updates-testing
$stg-koji add-tag --parent f28-container-updates-testing f28-container-updates-testing-pending
$stg-koji add-tag --parent f28-container-updates f28-container-updates-pending

The override tag is required as well:

$ bodhi releases create --staging --name "F28C" --long-name "Fedora 28 Containers" --id-prefix FEDORA-CONTAINER --version 28 --branch f28 --dist-tag f28-container --stable-tag f28-container-updates --testing-tag f28-container-updates-testing --candidate-tag f28-container-updates-candidate --pending-stable-tag f28-container-updates-pending --pending-testing-tag f28-container-updates-testing-pending --state current --override-tag f28-container-override

Warning: url and staging flags are both set. url will be ignored.

ERROR: Invalid tag: f28-container-override

Created the override tag:

$ stg-koji add-tag --parent f28-container-updates f28-container-override

@mohanboddu Can we do this again, since stg was sync'ed with prod and we lost the tags. This time we could do it for f29 this would allow us to test flatpak at the same time.

$stg-koji add-tag --parent f29-container f29-container-updates
$stg-koji add-tag --parent f29-container-updates f29-container-updates-candidate
$stg-koji add-tag --parent f29-container-updates f29-container-updates-testing
$stg-koji add-tag --parent f29-container-updates-testing f29-container-updates-testing-pending
$stg-koji add-tag --parent f29-container-updates f29-container-updates-pending
$stg-koji add-tag --parent f29-container-updates f29-container-override

• a new bodhi release

$ bodhi releases create --staging --name "F29C" --long-name "Fedora 29 Containers" --id-prefix FEDORA-CONTAINER --version 29 --branch f29 --dist-tag f29-container --stable-tag f29-container-updates --testing-tag f29-container-updates-testing --candidate-tag f29-container-updates-candidate --pending-stable-tag f29-container-updates-pending --pending-testing-tag f29-container-updates-testing-pending --state current --override-tag f29-container-override

On 08/29/2018 01:55 AM, Clement Verna wrote:

This time we could do it for f29 this would allow us to test flatpak at=
the same time.

If you want to test flatpak, we will also need a Flatpak release.

@mohanboddu Can we get the F29C release created in staging Koji again, as well as a Flatpak release?

CC @otaylor

For Flatpaks, in addition to an extra release, we'll also need a duplicate of the tag structure:

$ stg-koji add-tag --parent f29-flatpak f29-flatpak-updates
$ stg-koji add-tag --parent f29-flatpak-updates f29-flatpak-updates-candidate
$ stg-koji add-tag --parent f29-flatpak-updates f29-flatpak-updates-testing
$ stg-koji add-tag --parent f29-flatpak-updates-testing f29-flatpak-updates-testing-pending
$ stg-koji add-tag --parent f29-flatpak-updates f29-flatpak-updates-pending
$ stg-koji add-tag --parent f29-flatpak-updates f29-flatpak-override

$ bodhi releases create --staging --name "F29F" --long-name "Fedora 29 Flatpaks" --id-prefix FEDORA-flatpak --version 29 --branch f29 --dist-tag f29-flatpak --stable-tag f29-flatpak-updates --testing-tag f29-flatpak-updates-testing --candidate-tag f29-flatpak-updates-candidate --pending-stable-tag f29-flatpak-updates-pending --pending-testing-tag f29-flatpak-updates-testing-pending --state current --override-tag f29-flatpak-override

@cverna @otaylor @bowlofeggs Created the tags and releases for both f29 container and flatpaks in stagging koji and bodhi.

Also I set the state to pending in stg bodhi which is what current F29 status is and I dont think it matters, if it needs to be changed, please let me know.

Closing this, we now need to test it :smile:

Thanks