-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat: cache get-app artifacts by commit_hash #1519
Conversation
- put check_existing_dir back in its place
This will not allow rebuild btw (we allow doing it from FC dashboard 😬 ) |
message += " (compressed)" | ||
click.secho(message) | ||
|
||
os.chdir(app_path.parent) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If possible avoid changing directories. This has caused problems in past as bench assumes a certain directory to be cwd always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it's required cause of how tar functions, it stores the entire path and untarring requires moving the file out of nested directories. I've wrapped tar in a try
finally
so cwd
should be restored irrespective: 30f301e
Ah, I didn't know we allowed rebuilds. I suppose we can trigger |
Click supports pulling args from an envvar if it is present, this would be quicker and cleaner than calling a dummy command to check if the feature is supported
- ensure return to cwd after tarring
Note: ignoring SonarCloud Quality Gate It's failing due to potential tar bombs. It's failed in two places when creating the archive and when extracting it. When creating an archive: check is not necessary here cause the archive file is newly created and will be empty. Else that stack of code would not have run. When extracting from an archive: archive being extracted from is created by bench, and not user submitted, well the app repo could be, but in the given context it seems highly unlikely. (that being said I might add an Edit: filter added in #1523 |
🎉 This PR is included in version 5.21.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
TLDR: Stores
get-app
artifacts in.cache
bycommit hashcache key and reuses them when applicable.Partially Fixes: frappe/press#1242
TODO:
compress_artifacts
flag.frappe/esbuild/esbuild.js
to account for cached get-app. feat(Bench): add using-cached flag frappe#24412$BENCH/sites
is being updated properly.node_modules
for apps with built frontends (gameplan, insights, etc).Usage
Adds two new options to
bench get-app
:--cache-key
: Used to store tarred app folder in~/.cache/bench/apps
with the following format"{app}-{cache-key[:10]}.tar"
--compress-artifacts
: Optional flag that causes artifacts to be compressed using gzip, extension will then be.tgz
.Examples:
For either of the above if app is present in cache it will be fetched from there, else it will be stored in cache. While installing, cache is checked for both compressed and non compressed tar files.
Utility Commands
bench app-cache
bench app-cache --remove-app APP_NAME
bench app-cache --remove-key CACHE_KEY
Why?
When running
get-app
bench spends significant amount of time in git clone, yarn install, pip install, building frontend dependencies. If it's running get-app on the same code (same app, same repo, same commit hash),get-app
artifacts from the previous run can be reused.How?
After
get-app
has completed for some$APP
the relevant folders that change are:$BENCH/apps/$APP
: cloned source files, and built frontend files and dependencies.$BENCH/env
: python dependencies for the get-app'd$APP
.$BENCH/sites
: link to theassets/$APP
folder, updateassets.json
,apps.json
,apps.txt
.Caching the contents of
$BENCH/apps/$APP
covers repo cloning, yarn install and yarn build. That's what this PR facilitates.Reference
File system changes after running
get-app
forfrappe/hrms
.Regarding
$BENCH/env
Pip install does take a considerable amount of time but since it isn't contained in the app folder it won't be included for now. Future updates might have python dependencies stored inside the app folder. Out of scope for now.