Revive docker and add script for local headless test runs#283
Open
kaste wants to merge 19 commits intoSublimeText:masterfrom
Open
Revive docker and add script for local headless test runs#283kaste wants to merge 19 commits intoSublimeText:masterfrom
kaste wants to merge 19 commits intoSublimeText:masterfrom
Conversation
Follow-up to fe332f7 (fix sublime text 4 download link). Align the sbin Sublime Text installer with the ST4 URL fix already used in other setup paths. Using /download can return placeholder URLs (for example ${version}), which breaks archive downloads in local/docker runs.
This is a semantics and wording cleanup, not a bug fix. When Sublime Text is already present, the installer now reports a clearer message and exits with status 0. Returning success in this state matches common "ensure installed" script conventions and improves idempotent automation behavior.
Scheduler-driven runs previously forwarded only a small fixed subset of arguments to the `unit_testing` command. Allow schedule entries to include selected unit_testing option keys and forward them to `unit_testing`. This enables per-run overrides (for example pattern/tests_dir/failfast and reload_package_on_testing) without editing unittesting.json.
Keep the existing 2000ms default to preserve conservative behavior, while allowing local/container runs to experiment with lower values via UNITTESTING_SCHEDULER_DELAY_MS. In fact, "0" works fine on my local machine.
Document and harden the local containerized test path used by run_tests.py and docker entrypoints. This updates the docker/sbin workflow to better support repeated local runs with cache reuse, package refresh, and per-run test selection options. It also clarifies that sbin scripts remain relevant for local container automation even though GitHub CI prefers actions/*.
Enforce LF line endings for docker and sbin shell scripts via .gitattributes so Linux container execution remains reliable. Also normalize ci.sh when sourced from mounted UnitTesting checkouts and normalize copied UnitTesting sbin scripts in the container as a runtime safety net for existing Windows working trees.
Set docker/run_tests.py --scheduler-delay-ms default to 0 to match observed local behavior where immediate scheduling is sufficient. Keep the option so callers can raise the delay explicitly if needed.
Configure a global git user.name and user.email in the local Docker entrypoint when they are missing. This makes local container runs behave more like GitHub CI for tests that create commits, while still allowing overrides via existing git config or UNITTESTING_GIT_USER_NAME/UNITTESTING_GIT_USER_EMAIL.
Export TRAVIS_OS_NAME from uname when unset so older test suites that still use Travis-style platform checks behave consistently in local container runs. This keeps existing values intact if TRAVIS_OS_NAME is already provided.
Populate RUNNER_OS from uname when unset, alongside TRAVIS_OS_NAME, so test suites using GitHub Actions-style OS detection behave consistently in local container runs.
Add docker/ut-run-tests and docker/ut-run-tests.cmd as simple, stable entrypoints for local containerized runs without uv project coupling. Update docs to recommend the launcher command and keep run_tests.py as the underlying implementation detail.
Replace low-level image build/pull knobs with user-facing lifecycle flags: - --refresh-image rebuilds the local image - --reset-cache recreates the cache volume - --fresh does both Keep automatic rebuilds when the docker context changes or the image is missing, and document how to refresh Sublime/Package Control state without direct docker commands.
Add --reload-package-on-testing to docker/sbin local runner CLI and pass it through to scheduled test options. Set reload_package_on_testing to false by default in generated schedule entries, so local runs avoid package reload unless explicitly requested.
Print static runtime metadata in sbin/run_tests.py before writing and executing the schedule: - Sublime Text version (via `subl --version`) - Package Control version (from installed package metadata) This makes local run logs self-describing for troubleshooting and future build/version freshness checks.
Add a local runner dry-run mode that prints runtime metadata and the generated schedule without executing tests. Also route the option through docker -> sbin runner and document it in README files.
Only pass -i when stdin is a TTY and -t when stdout is a TTY. This prevents `docker run` from failing with "the input device is not a TTY" when the local runner is executed from non-interactive environments (like the agent harness) while preserving interactive behavior in regular terminals.
Add a --color flag to the local docker runner and pass it through to sbin/run_tests.py. Implement ANSI colorization for streamed unittest output so per-test statuses and final summaries are easier to scan: - ok in green - skipped in yellow - FAIL/ERROR in red - "Ran ..." summary in cyan Color mode supports auto/always/never and respects NO_COLOR, FORCE_COLOR, and CLICOLOR_FORCE in auto mode. Keep non-color mode as a fast raw passthrough path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a local test runner based on docker for headless and painless test runs.
E.g.
docker was deprecated, so I first had to revive it. Then it was also very inconvenient to use. So I added an actual script that wires all that docker handling.
For fast execution, the image is cached after ST and PC are installed. So consecutive invocations only
rsyncthe package-under-test into the image.The main benefit is obviously: fast execution without getting interrupted as the own instance of Sublime Text is not trapped.
Obviously, we would need a deploy strategy as the installed UnitTesting is in a zip, and hence the contained docker/* would be not useable out of the box. Easy-peasy solution is to just install it unpacked. Then we know its path and could recommend build systems that target the new
docker/ut-run-tests.Tested against UnitTesting, SublimeLinter and GitSavvy under bash for Windows (11, Pro). On Windows
is your friend. Pro might be required, IIRC it was at some point.