Hello all,
I didn't know specifically where to throw this email so I just
went to the atomic-devel list and added folks to the thread who I
wasn't sure would be on the list. If I missed anyone please feel free
to add them to the thread.
Alright, so I want to start with the prereq that this is not meant to
be the long term solution and we already have plans to improve it but
we're in a time crunch at the moment.
It was brought up that we need a way to mark a compose build artifact
as "bad" even if the automated testing says it's good in (think
security vulnerability or known bug that we just don't yet have a test
case for). The following is my draft proposal I would like feedback
on.
Draft Proposal:
For the time being until we have a more appropriate solution, let's
have a mark-atomic-bad git repo in pagure.io that contains a single
json file called bad-builds.json (I don't care what we call either of
these things, the names are place holders). In that file we define bad
builds similar to:
{
"bad_builds": [
"Fedora-Cloud_Atomic-x86_64-22-20150910.iso ",
]
}
(Those builds aren't bad, I just needed an example)
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 can pull that in, parse it and easily
check to make sure the passed build candidate isn't known to be bad.
It's not ideal but it would work and would be simple to implement.
If anyone would like more information on this specific topic, we're
tracking it in taiga:
http://taiga.cloud.fedoraproject.org/project/acarter-fedora-docker-atomic-tooling/us/20
Thank you,
-AdamM
