Implement repo:gc and repo:purge-cache #2050
Conversation
|
Do we need this given that we only clone a depth of 1? Also, tests. |
plugins/repo/subcommands/purge-cache
Outdated
| local APP="$2"; local CACHE_DIR="$DOKKU_ROOT/$APP/cache" | ||
| verify_app_name "$APP" | ||
|
|
||
| find "$CACHE_DIR" -mindepth 1 -exec rm -rf {} |
There was a problem hiding this comment.
Does this work? Check the apps pre-delete trigger. We mount a container to rm this in that case due to permissions.
|
Couldn't we implement |
c2f48b5 to
1b7b632
Compare
|
|
Oh yeah that's fair. We clone a depth of one but each subsequent push will add to that history. |
|
Thinking further, download would either need a client or we could tar up to a directory and just echo out the path for the user to scp. Not sure how much it's worth to do though. Also, write some damn tests. 😜 |
|
No, u. |
|
You could prevent the race condition by using |
|
I figure the |
|
👍 |
|
How do I test the |
|
Rebased from master and added tests |
|
Uhh that's not a rebase ;) |
|
Hrm what happened there? I did |
fe78831 to
faba89c
Compare
|
I think that fixed it. Maybe those showed up because we're merging squashed commits when we merge PRs? |
|
I cherry-picked that last commit from master. Not sure why github shows it as a change since the files match.... |
These are helper plugins that mimic the repo plugin: https://github.com/heroku/heroku-repo The following commands will remain unimplemented: - `clone`: not useful for the host client to clone - `download`: currently not possible for us to "host" a tarball of the repo - `reset`: we still store files in the repo (though we shouldn't) so we cannot easily reinitialize the repository. Also fixes a potential race condition if two separate processes create an application's `$CACHE_DIR`. Closes #1570
49e2a3f to
48965e0
Compare
These are helper plugins that mimic the repo plugin: https://github.com/heroku/heroku-repo
The following commands will remain unimplemented:
clone: not useful for the host client to clonedownload: currently not possible for us to "host" a tarball of the reporeset: we still store files in the repo (though we shouldn't) so we cannot easily reinitialize the repository.Also fixes a potential race condition if two separate processes create an application's
$CACHE_DIR.Closes #1570