Discussion: Build Management

[askreet]

@ghaabor introduces a list-builds command in #82, which highlights a very real need for the Moonshot pattern: builds management.

I see 3 basic needs:

• I need to see what builds I have available for deployment or deletion.
• I need to delete an old, unused build to save money on S3 fees, etc.
• I need an automated way to prune "one-and-done" developer builds.

I wonder if we want to use a Thor Subcommand pattern for the CLI interface, like:

bin/environment builds list --filter=release
bin/environment builds prune --filter=dev --days=30
bin/environment builds delete v1.0.7-rc2

I have a couple questions I'd love feedback on:

• Should we tag the developer one-off builds created by deploy-code in some meaningful way that can be used generically by ArtifactRepositories? If so, should prune only work with those builds as safety mechanism?
• Should we move this functionality outside Moonshot?

Thoughts?

[janost]

@askreet I like your CLI proposal.
As for deleting old builds, I believe prune should only delete the dev builds generated by deploy-code.
This seems to be a very useful feature for most users, implementing it as a core functionality would be great.

[unn]

I'm 👍 for supporting this in moonshot.

[ghaabor]

Sorry for the late answer, I'm on vacation this week. I like the idea of extending moonshot with a builds subcommand and I think all three of your CLI proposals are perfectly valid.

For your questions:

• I think pruning for one-time builds is a great idea bit it should not effect custom-named builds.
• I agree with @janost, this would be an important part related to core moonshot functionality so I'm on the side of not moving it out.