Hi,Is there some cleaning process in Brew that is removing some builds? Can a build be not tagged?We need to be able to test whole pipeline from source to openshift image for each Pull Request. That produces a lot of builds with short lifespan, these builds will not be needed after some short time anymore, so they can be safely deleted so we don't burden our resources.So how could this be handeled in Brew?HonzaOn Wed, Nov 29, 2017 at 5:53 PM Michael McLean <email@example.com> wrote:On Wed, Nov 29, 2017 at 9:10 AM, John Casey <firstname.lastname@example.org> wrote:Okay, some answers I got on IRC:* Koji doesn't have scratch builds, only scratch tasks. Since CG only imports builds and doesn't create tasks, it circumvents the scratch feature in KojiCorrect. The point of scratch builds is that they are not in the system. The analog of a scratch build for a CG would be to simply not import it.* Koji will allow us to store a flag in the extra field of the imported build metadata, which would allow us to mark a build as "scratch" without using that feature in Koji itselfWhile the extra portion of build metadata is essentially free form, I recommend caution when adding new data. Currently there is no standard for this in any of the CG docs.It is unclear to me what this would really mean in practice. A build that is fully imported into Brew is not really a scratch build is it? It would certainly not share the limitations of regular Brew scratch builds.Would it be better to use a tagging process here instead? Do we need a different term?* An external system could look for this scratch flag and untag imported builds (after some grace period)Why tag them in the first place then?-johnThanks,* Normal Koji GC would clean up untagged, imported builds normally (again, after some period elapses)I just wanted to get that down in this thread to avoid confusion.On Wed, Nov 29, 2017 at 7:24 AM, John Casey <email@example.com> wrote:-johnThanks,We're trying to create a system where each PR triggers a whole workflow of builds and test runs. However, in these cases we KNOW these are not shippable builds, so we want to make them ephemeral in all of the build systems. Obviously, cleanup tasks become a concern here, since we will probably be doing many of these builds.Hi,I'm wondering if it's possible to import builds (via content generator) as scratch builds, so they get cleaned up automatically at some point in the future?We're working on a system that will be doing continuous development / continuous delivery, and spans three different build systems. One is Koji, but the other two will use Koji's content generator interface for passing build data between the different systems.I think we could probably untag builds in Koji from an external system in order to trigger GC of these temporary builds, but it seems like it would be simpler to use a native cleanup routine in Koji.Is this feasible?