-
Notifications
You must be signed in to change notification settings - Fork 22
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
improved build workflow #272
Conversation
Codecov Report
@@ Coverage Diff @@
## main #272 +/- ##
==========================================
- Coverage 93.44% 91.49% -1.95%
==========================================
Files 34 41 +7
Lines 2028 2223 +195
==========================================
+ Hits 1895 2034 +139
- Misses 133 189 +56
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@@ -68,7 +68,7 @@ def load_manifest_from_CxG() -> List[Dataset]: | |||
logging.info(f"Found {len(datasets)} datasets, in {len(collections)} collections") | |||
|
|||
# load per-dataset schema version | |||
with concurrent.futures.ThreadPoolExecutor(max_workers=16) as tp: | |||
with concurrent.futures.ThreadPoolExecutor(max_workers=32) as tp: |
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.
Is there a specific reason for which this isn't parametrized as well?
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.
no good reason, other than we had no prior need. I'll add a config for it so it can be overridden. It can't use the standard worker config, as it controls the concurrent HTTP requests. The only reason we have any value here (rather than use the thread pool default) is to keep from overwhelming the Discover REST backend.
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.
We could call it max_io_workers
.
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.
with the recent improvements to the Discover backend, this works fine using the system defaults for ThreadPoolExecutor so I simply removed the config entirely.
``` | ||
working_dir: | ||
| | ||
+-- config.yaml # build config (user provided, read-only) |
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.
Could be useful to provide an example config.yaml that can be copied as necessary.
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.
sure. later info in this doc points the user at the build_state.py file. And by default you should not specify a config file if doing the standard census build. It is only for dev reasons that you would use it.
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.
example added, plus verbiage about not needing to provide a config for the standard
census build
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.
rename to dev-config.yaml
?
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.
I would rather leave as-is. It is the config, for any purpose. I just have defaults set so that it isn't required in our current workflow, but I can easily imagine situations where it is used in the future.
that said, if you feel strongly, I'm not going to force this issue :-)
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.
LGTM, but made a few usability/doc-related comments, plus:
- The docker build failed on M1 ("numpy not found"), so attempted on EC2 Ubuntu instance, which worked. (Did not troubleshoot M1, since I don't think it's necessary to be able to build locally.)
- On EC2, needed to install docker by following https://docs.docker.com/engine/install/ubuntu/#installation-methods and https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user. Worth noting in the README? Even though we intend to run this in Batch, I assume we'll be testing on EC2 on occasion.
- Add
build
tools/cell_census_builder/requirements-dev.txt for times you are trying to build image locally (not via GHA).
``` | ||
working_dir: | ||
| | ||
+-- config.yaml # build config (user provided, read-only) |
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.
rename to dev-config.yaml
?
tools/cell_census_builder/README.md
Outdated
``` | ||
$ mkdir /tmp/census-build | ||
$ chmod ug+s /tmp/census-build # optional, but makes permissions handling simpler | ||
$ docker run --mount type=bind,source="`pwd`/tmp/census-build",target='/census-build' cell-census-builder |
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.
$ docker run --mount type=bind,source="`pwd`/tmp/census-build",target='/census-build' cell-census-builder | |
$ docker run --mount type=bind,source="/tmp/census-build",target='/census-build' cell-census-builder |
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.
rm $
prompts for easier copy & paste; also add markdown type: "```shell" as first line (here & above)
|
||
https://docs.google.com/document/d/1GKndzCk9q_1SdYOq3BeCxWgp-o2NSQkEmSBaBPKnNI8/ |
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.
Unless running from Batch is right around the corner, worth keeping this link or moving its contents here. E.g. you still need to know how to provision EC2 instance and setup swap.
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.
this was a link to an obsolete schema spec, which I replaced with the correct link. It was not a build process doc, which has never been part of this README (and probably should not IMHO given that it contains internal infra info).
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.
ps. once I get all this landed, and refined, I will update the "manual build process" doc, not linked here.
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.
ah, great!
docker system prune | ||
docker rm -f $(docker ps -aq) | ||
docker rmi -f $(docker images -q) | ||
``` |
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.
Move into a Makefile target for convenience?
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.
excellent idea.
from importlib import metadata | ||
except ImportError: | ||
# for python <=3.7 | ||
import importlib_metadata as metadata # type: ignore[no-redef] |
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.
nit: support for <=3.7 doesn't seem necessary
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.
and the pyproject.toml defines supported releases as 3.9 and 3.10, so this change is consistent with that.
@atolopko-czi - can you provide more details on this failure? While I agree we do not support M1 Macs, this is an unexpected failure as |
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.
LGTM!
Will recreate the numpy error later and report back.
|
||
https://docs.google.com/document/d/1GKndzCk9q_1SdYOq3BeCxWgp-o2NSQkEmSBaBPKnNI8/ |
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.
ah, great!
This implements most of what is required to complete #265. Specifically, it dockerizes and automates the
full
census build steps 1-3:It stops short of the remaining steps for a full release:
Changes in this PR:
cell_census_builder
converted to installable package, with sub-modules that perform different build steps. Each sub-module has a separate__main__
to allow for continued stand-alone use. Used asrc
layout for easy packaging with setuptoolsCensusBuildArgs
,CensusBuildConfig
andCensusBuildState
which unifies the static and dynamic state across all builder sub-modules. This replaces the use ofargparse.Namespace
for configuration.build_soma
sub-module. This includes splitting__main__.py
into multiple files, moving all files down into a sub-module calledbuild_soma
, etc.host_validation
which performs checks on host config/resources. Intended to be used as a prologue to a build, e.g., confirming sufficient memorycensus_summary
into the package as a sub-moduletools/scripts
as they will be used outside of the eventual containerNotes for reviewers: no major changes to the build or summary modules. Changes are primary around configuration and creating a new top-level workflow that has defaults suitable for the full Census build. There is also other cleanup and reorganization that could be done (e.g., breaking up the
build_soma
sub-module into smaller chunks), but I'd rather do that progressively, as this PR is getting way too big....