Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Sign in
Toggle navigation
Menu
Open sidebar
SimStadt
simstadtpy
Commits
3f69ed7d
Commit
3f69ed7d
authored
Sep 19, 2026
by
Eric Duminil
Browse files
Only one image
parent
7907da59
Changes
2
Show whitespace changes
Inline
Side-by-side
Dockerfile
View file @
3f69ed7d
...
@@ -39,26 +39,34 @@ FROM base AS cli
...
@@ -39,26 +39,34 @@ FROM base AS cli
# `simstadt` is unpinned (always the latest PyPI release), and `simstadt --install`
# `simstadt` is unpinned (always the latest PyPI release), and `simstadt --install`
# always fetches the latest SimStadt build — there's no version/URL override available
# always fetches the latest SimStadt build — there's no version/URL override available
# for either today. This is a deliberate tradeoff for a "real, current"
CLI
image, not
# for either today. This is a deliberate tradeoff for a "real, current" image, not
# an oversight: it means the build needs network access, and rebuilding this stage later
# an oversight: it means the build needs network access, and rebuilding this stage later
# can silently bake in different simstadt/SimStadt versions than a previous build.
# can silently bake in different simstadt/SimStadt versions than a previous build.
RUN
uv venv
"
$VIRTUAL_ENV
"
&&
uv pip
install
simstadt
COPY
--chown=simstadt:simstadt pyproject.toml uv.lock README.md ./
RUN
uv
sync
--frozen
--no-install-project
# `uv pip install` (unlike `uv sync`) doesn't consult uv.lock: a future published `simstadt`
# release could bump a shared runtime dep (matplotlib/numpy/pandas/...) past what the frozen
# sync above just pinned, silently upgrading it. Accepted for now, same spirit as leaving
# `simstadt` itself unpinned below — revisit with `uv pip install --constraint` if it bites.
RUN
uv pip
install
simstadt
RUN
simstadt
--install
RUN
simstadt
--install
CMD
["simstadt"]
# tests/ is copied last (after the network-bound `simstadt --install`) so editing a test
# doesn't invalidate that layer's cache. It also means a future consumer using this image as
FROM
base
AS
test
# a base (see the design doc's ":cli as a candidate FROM base" note) would inherit tests/ and
# the pytest/pytest-cov/rich dev group as dead weight — a known, small, accepted cost of
COPY
--chown=simstadt:simstadt pyproject.toml uv.lock README.md ./
# this image serving two purposes (runtime + release smoke test) from one artifact.
COPY
--chown=simstadt:simstadt src ./src
COPY
--chown=simstadt:simstadt tests ./tests
COPY
--chown=simstadt:simstadt tests ./tests
RUN
uv
sync
--frozen
# This image tests the PUBLISHED simstadt package (from PyPI) against a real SimStadt/INSEL
# install — a release/environment smoke test, not a pre-publish check of local changes
RUN
simstadt
--install
# (which `make simple_tests` already covers via mocks, no Docker/real SimStadt needed).
# Tests are run via an explicit `docker run <image> <test-command>` override (see the
# No `-m "not integration"` filter here, deliberately: this image has a real SimStadt/INSEL
# Makefile's `docker-test` target: `uv run --no-sync pytest -v`). Plain `uv run pytest -v`
# install (unlike a plain dev machine or CI runner), so its whole point is to run the full
# is deliberately NOT used here since this stage never copies `src/`, so `uv run`'s implicit
# suite. The `simple_tests` Makefile target remains the one for the non-integration subset.
# sync would try (and fail) to build/install the local project from a nonexistent `src/`.
CMD
["uv", "run", "pytest", "-v"]
# `--no-sync` skips that; plain `pytest -v` would also work (the venv's `bin/` is already on
# `PATH` via `base`), but `uv run --no-sync` was chosen to match this repo's other test
# targets' `uv run` style.
CMD
["simstadt"]
Makefile
View file @
3f69ed7d
...
@@ -22,19 +22,17 @@ shell: ## Start bash
...
@@ -22,19 +22,17 @@ shell: ## Start bash
@
echo
"
${green}
Start shell
${no_color}
"
@
echo
"
${green}
Start shell
${no_color}
"
docker run
--rm
-it
simstadt/simstadt:cli bash
docker run
--rm
-it
simstadt/simstadt:cli bash
docker-build
:
##
Build the cli
and test
Docker image
s
docker-build
:
##
Build the cli Docker image
docker build
--target
cli
-t
simstadt/simstadt:cli .
docker build
--target
cli
-t
simstadt/simstadt:cli .
docker build
--target
test
-t
simstadt/simstadt:test .
docker-test
:
docker-build
##
Run the full test suite (incl. integration tests) inside Docker
docker-test
:
docker-build
##
Run the full test suite (incl. integration tests)
against the published PyPI package
inside Docker
docker run
--rm
simstadt/simstadt:test
docker run
--rm
simstadt/simstadt:
cli uv run
--no-sync
py
test
-v
_check_docker_push
:
_check_docker_push
:
@
echo
-n
"Are you sure you want to push the Docker images to Docker Hub? [y/N] "
&&
read
ans
&&
[
$
${
ans
:-
N
}
=
y
]
@
echo
-n
"Are you sure you want to push the Docker images to Docker Hub? [y/N] "
&&
read
ans
&&
[
$
${
ans
:-
N
}
=
y
]
docker-push
:
_check_docker_push docker-build
##
Push
cli and test
image
s
to Docker Hub (requires prior `docker login`)
docker-push
:
_check_docker_push docker-build
##
Push
the cli
image to Docker Hub (requires prior `docker login`)
docker push simstadt/simstadt:cli
docker push simstadt/simstadt:cli
docker push simstadt/simstadt:test
tests_installed_package
:
##
Tests the installed simstadt package
tests_installed_package
:
##
Tests the installed simstadt package
pytest
--pyargs
simstadt
-v
pytest
--pyargs
simstadt
-v
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment