README.md

mark-atomic-bad

This git repository is meant to simply store a json file that allows for members of the Fedora Cloud Working Group who are involved with the Fedora Two Week Atomic build pipeline to mark a known bad compose of Fedora's Atomic images as bad even if the automated testing passes. This would happen for scenarios where a known vulnerable package made it into the image compose or if there's a known bug but there is yet to be a test case for it in the automated testing.

This is not meant to be the long term solution and we already have plans to improve it but the database to track all the compose artifacts (PDC) will not be production ready in Fedora space in the short term.

This way pagure.io handles the authentication/authorization piece, it offers a common entry point (git) and we can grant a select group of people permission to push to master (Atomic Dev Team, Fedora QE, Rel-Eng, $other?)

Then automatic release script will pull the files, parse them and easily check to make sure the passed compose candidate isn't known to be good or bad, the release is blocked or not.

bad-composes.json

In the bad-composes.json file we define bad composes such as:

{
    "bad-composes": [
        "Fedora-Atomic-24-20160701.0",
        "Fedora-Atomic-24-20160702.0"
    ]
}

(Those builds aren't bad, I just needed an example)

good-composes.json

This repository now also serves as an entry point to mark a compose as known good in the event of a false positive failure for the AutoCloud system.

In the good-composes.json file we define the good composes such as: { "good-composes": { "Fedora-Atomic-24-20160701.0", "Fedora-Atomic-24-20160702.0" }

block-release.json

There is also a file called block-release.json which is a stop-gap to handle the ability to manually gate a release in the short term for the sake of Fedora Two Week Atomic. This will also be replaced by a more permanent solution around PDC at a later date.

This is a simple true or false value that anyone with commit access to this git repository can set and it will be checked at the start of the Two-Week Atomic release script.

{
    "block-release": false
}

The "block-release" value is reset to false by Release Engineering after each successful release.