RFE: finer grain controls for pruning

[dustymabe]

As we start to march towards a unified repo for Fedora Atomic Host we need more control around pruning. Some examples include:

• being able to prune specific branches (refs). i.e. I want to prune commits in fedora/26/x86_64/testing older than 30 days
• (optional) the ability to protect some commits from pruning (kind of like preventing a force push to your git master branch). we could 'protect' any commit that we did an official release of Fedora for. If we did this then i would feel more comfortable with setting up a process to 'autoprune' the ostree repo.
• (optional) adding a feature to delete all static deltas in branch history for fedora/26/x86_64/atomic-host that don't point to commit=xxyyzz. This would enable us to prune all static deltas that don't point to the latest commit for a ref.

[cgwalters]

(optional) the ability to protect some commits from pruning (kind of like preventing a force push to your git master branch).

Since FAH today doesn't use https://github.com/ostreedev/ostree-releng-scripts/blob/master/do-release-tags - the whole commit stream needs to be protected right? We could prune the "not released" commits but as soon as we did that it would completely break the ability to traverse the history.

This is another reason to do commit promotion like that script implements.

[cgwalters]

PR in #1127

[dustymabe]

Since FAH today doesn't use https://github.com/ostreedev/ostree-releng-scripts/blob/master/do-release-tags - the whole commit stream needs to be protected right? We could prune the "not released" commits but as soon as we did that it would completely break the ability to traverse the history.

I guess you are right, unless we did something like #954

This is another reason to do commit promotion like that script implements.

doesn't that script create a new commit when it promotes a release? While that does make the history cleaner, one drawback is that we no longer are running tests against the same commit that is released. Technically it's the same so I guess it doesn't matter, but it's really nice when the hash we test against doesn't change.

One alternative approach would be for us to compose each time using the previous two week release ref as the 'starting point'. We wouldn't need to do-release-tags but we'd also have no history for our updates ref. This is worth some more discussion at some point.

[cgwalters]

New commit, same content. We talked in person before about having ostree display a "content hash" instead of commit.

[cgwalters]

(Well s/instead of/in addition to/ and there's clearly lots of implications from that - big picture though I think we should focus on version identifiers...so the promoted commit would have the same version and we'd treat that the same)