Option to install gems for only target ecosystem in dev shell#5520
Option to install gems for only target ecosystem in dev shell#5520
Conversation
This speeds up build time of the dev shell if you only need to work with a particular ecosystem.
jeffwidman
left a comment
jeffwidman
left a comment
There was a problem hiding this comment.
It's neat and we should merge it, but one nit is that it's not really discoverable for new users of the dev shell.
Since this isn't the dry-run script, I'm not exactly sure how to make this discoverable... if we should be printing potential args at the beginning fo the script run, IDK... and potentially part of this may be replaced (at least partially) by the upcoming work of splitting out the docker images (at least if we end up going down that route) so right now it's not worth investing additional time into docs/discoverability... but something to keep in mind on whenever we add more dev options
| COPY --chown=dependabot:dependabot python/Gemfile python/dependabot-python.gemspec ${CODE_DIR}/python/ | ||
| COPY --chown=dependabot:dependabot pub/Gemfile pub/dependabot-pub.gemspec ${CODE_DIR}/pub/ | ||
| COPY --chown=dependabot:dependabot terraform/Gemfile terraform/dependabot-terraform.gemspec ${CODE_DIR}/terraform/ | ||
| ARG TARGET_ECOSYSTEM= |
There was a problem hiding this comment.
Maybe add a code comment right above that says "If specified, will only build that ecosystem. Blank will build for all ecosystems. Speeds up any debugging that requires recompiling an ecosystem".
I realize that increase the risk of the comment going out of sync with the code, but in this case it's worth it IMO simply for discoverability if someone is skimming the source it's super easy to miss that this flag exists.
jurre
left a comment
jurre
left a comment
There was a problem hiding this comment.
Nice one! Maybe stick a note in the README?
deivid-rodriguez
left a comment
deivid-rodriguez
left a comment
There was a problem hiding this comment.
I run into this just yesterday and it was indeed painfully slow! So thanks!! :)
Maybe a silly question, but I see that all these Gemfiles only install the dependencies in common/. Would it be a bad idea to share this gem location accross ecosystems? Just saying because that would make this fast by default.
|
This is what I was thinking: #5528. Not sure if it works but makes sense to me in principle? |
Oh interesting, I didn't realize the gems aren't customized for any of the ecosystems! I think sharing them would make more sense although it would make it harder to add a gem to a single ecosystem in the future. That may not be a problem given it hasn't happened yet. |
|
Yeah! It that happened, I think it might still work, just the other environments would have one unused gem available. But we could split out that single bundle anyways (partially rolling this back indeed, so with some extra work). Anyways, I think we can give #5528 a try and see if it has any unexpected side effects! |
|
FYI: there are some places where we do install dependencies outside of the common gemspec, not sure if that matters in this context We could also move it into common if it's painful otherwise? |
Aha, nice find! I think that means the submodule updater would be missing that gem with #5528? If that's the only case I wouldn't be opposed to moving it to common as that makes the dev containers faster to build/easier to use for everyone. Does it make sense to install the gems for the omnibus first since that should include dependencies from all the sub-projects? ex: #5529 |
4 participants
This speeds up build time of the dev shell if you only need to work with a particular ecosystem. Installing gems for all ecosystems takes a long time so this flag allows you to only install them for a particular ecosystem. You'll be able to dry-run/test the target ecosystem but you'll need to rebuild or manually install gems to work with others.
My bash skills are a bit rusty so open to any tips on improving this as well!