New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: finer grain controls for pruning #1115

Closed
dustymabe opened this Issue Aug 25, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@dustymabe
Contributor

dustymabe commented Aug 25, 2017

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.

@jlebon jlebon added the enhancement label Aug 25, 2017

@cgwalters

This comment has been minimized.

Member

cgwalters commented Sep 1, 2017

(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 added a commit to cgwalters/ostree that referenced this issue Sep 1, 2017

bin/prune: Port to new style
No functional changes, all straightforward.  Prep for
ostreedev#1115

cgwalters added a commit to cgwalters/ostree that referenced this issue Sep 1, 2017

bin/prune: Add --only-branch
In 5c94098 / ostreedev#646 we
added `--retain-branch-depth`; this adds a symmetric
`--only-branch` for the case where a repo owner just
wants to prune a specific branch.

The implementation here is pretty straightforward; we
just walk all refs and inject the equivalent of
`--retain-branch-depth=$ref=-1` if they're *not* in
`--only-branch`.

Closes: ostreedev#1115
@cgwalters

This comment has been minimized.

Member

cgwalters commented Sep 1, 2017

PR in #1127

rh-atomic-bot added a commit that referenced this issue Sep 1, 2017

bin/prune: Port to new style
No functional changes, all straightforward.  Prep for
#1115

Closes: #1124
Approved by: jlebon

cgwalters added a commit to cgwalters/ostree that referenced this issue Sep 7, 2017

bin/prune: Add --only-branch
In 5c94098 / ostreedev#646 we
added `--retain-branch-depth`; this adds a symmetric
`--only-branch` for the case where a repo owner just
wants to prune a specific branch.

The implementation here is pretty straightforward; we
just walk all refs and inject the equivalent of
`--retain-branch-depth=$ref=-1` if they're *not* in
`--only-branch`.

Closes: ostreedev#1115
@dustymabe

This comment has been minimized.

Contributor

dustymabe commented Sep 8, 2017

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

This comment has been minimized.

Member

cgwalters commented Sep 8, 2017

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

@cgwalters

This comment has been minimized.

Member

cgwalters commented Sep 8, 2017

(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)

cgwalters added a commit to cgwalters/ostree that referenced this issue Sep 12, 2017

bin/prune: Add --only-branch
In 5c94098 / ostreedev#646 we
added `--retain-branch-depth`; this adds a symmetric
`--only-branch` for the case where a repo owner just
wants to prune a specific branch.

The implementation here is pretty straightforward; we
just walk all refs and inject the equivalent of
`--retain-branch-depth=$ref=-1` if they're *not* in
`--only-branch`.

Closes: ostreedev#1115
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment