Pruning policy for builds about coreos-assembler HOT 5 CLOSED

Would be nice to make it configurable, but I could see that being a problem too. Really people should be archiving the outputs somewhere else if they want to keep things around.

from coreos-assembler.

I'm in the process actually right now of using c-a and archiving the builds to s3. My current approach here is to just sync in the previous build's metadata (I may try to land some of this code in c-a at some point).

This also implies that GC of jobs lives outside of this repo.

So we need to split this discussion into "local development" versus production.

Personally for the local dev case I just coreos-assembler clean periodically.

from coreos-assembler.

Yeah, for prod we definitely want to encourage syncing somewhere else.

My current approach here is to just sync in the previous build's metadata

OK yeah, that makes sense. Though that sounds like syncing in/out should be outside of this repo, right? I.e. instead of hardcode a specific service here. Or maybe we could support passing a link to init to a hosted build dir from which we pull the previous build metadata.

Personally for the local dev case I just coreos-assembler clean periodically.

OK, let's consider #140 as targeting the local dev case. Will follow up there.

from coreos-assembler.

This looks like it added reverse=True to the builds.json sorting order right?

Before:

json.dump({"builds":
           list(map(lambda x: x[0], sorted(builds, key=lambda x: x[0])))},

After:

builds = sorted(builds, key=lambda x: x[1], reverse=True)

Was that intentional? I guess we should just move forward with it.

from coreos-assembler.

Yes, it was. Just seemed nicer to have the most recent one be first since that's what we're most interested with.

from coreos-assembler.