feat: root volume configuration (volume-size/type/iops/throughput)#52
Merged
Conversation
…uts)
The action offered no control over the root volume — instances inherited the
AMI's block-device mapping (Amazon Linux 2023: 8 GiB gp3), which Docker-based CI
exhausts almost immediately ("no space left on device"). New start-mode inputs:
volume-size GiB, must be >= AMI snapshot size
volume-type gp3 (recommended) | gp2 | io1 | io2
volume-iops io1/io2/gp3 only
volume-throughput gp3 only (MiB/s)
- Unifies the root block-device mapping into a single builder
(buildRootDeviceMapping) so encryption (encrypt-ebs) and sizing compose in one
mapping instead of two competing BlockDeviceMappings writers.
- DeleteOnTermination is always forced true so resized/ephemeral volumes never
leak (explicitly asserted).
- Validation: type/iops/throughput combinations checked at config parse (fail in
seconds); size-vs-AMI-snapshot checked against the DescribeImages data already
fetched for encryption, erroring with both numbers.
- Omitted inputs leave the AMI default untouched — no BlockDeviceMappings is
emitted at all (zero-diff regression covered by wantsRootDeviceMapping tests).
Tests: mapping builder (encryption/sizing/compose/DeleteOnTermination/null cases/
size-below-snapshot), config combo validation, opt parsing (128 tests total).
README "Disk space for Docker workloads" note + inputs table and action.yml
descriptions added.
Closes #44
Signed-off-by: kurok <22548029+kurok@users.noreply.github.com>
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.
Closes #44 — roadmap (#49); small, self-contained, high frequency-of-pain.
Problem
No control over the root volume — instances inherit the AMI mapping (AL2023: 8 GiB gp3). Docker CI exhausts that instantly →
no space left on device, one of the most common self-hosted-runner failures.New inputs (start mode)
Design
buildRootDeviceMappingcomposes encryption (encrypt-ebs) and sizing into a single root mapping — replaces the encryption-onlybuildEncryptedRootMapping.DeleteOnTermination: trueis always forced (explicitly asserted), even if the AMI set it false.BlockDeviceMappingsis emitted at all — AMI default preserved byte-for-byte (covered bywantsRootDeviceMappingregression tests).Tests / build
tests/ebs.test.jsrewritten for the unified builder (encryption, sizing, compose, DeleteOnTermination, null cases, size-below-snapshot), plus config combo-validation and opt-parsing tests. 128 tests pass (was 108). Lint clean, dist rebuilt (verify-dist green).Docs
Compatibility
encrypt-ebs-only behavior is byte-identical apart fromDeleteOnTerminationnow being explicit (previously inherited from the AMI, normally already true).