On Wed, Nov 29, 2017 at 9:10 AM, John Casey <jcasey(a)redhat.com> 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
Correct. 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
build metadata, which would allow us to mark a build as "scratch" without
using that feature in Koji itself
While 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
* An external system could look for this scratch flag and untag
builds (after some grace period)
Why tag them in the first place then?
* Normal Koji GC would clean up untagged, imported builds normally
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 <jcasey(a)redhat.com> wrote:
> 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.
> 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.
> 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?
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org