Elysia Tools
Navigation
Workflow Playbook
Review Dockerfile findings, validate image references, expose duplicate environment keys and explain staging-to-production drift in one container release record.
Hubs
This workflow helps an application maintainer prepare a container release review. Keep the Dockerfile, image reference and environment snapshots tied to one revision. Mixing an old staging file with a new production file creates false drift. Write the required-key checklist from application expectations, including ports, service endpoints and feature flags. Sanitize secrets before using any shared tool while preserving key names and meaningful nonsecret values. Keep secret-change status in an appropriate private record; identical placeholders do not demonstrate identical credentials. For a fuller disclosure review, use pii-log-redaction.
Use dockerfile-linter to inspect line-level findings around base-image pinning, package hygiene, user selection and configuration embedded in the build. Resolve relevant findings or record the reason and owner of an exception. The tool does not build the image or scan its installed dependencies. Check base and application references with docker-image-tag-validator, then record the actual artifact identity from CI. A legal repository and tag string cannot prove that the registry contains it or that the target machine can pull and execute it.
Run env-parser on sanitized text before reducing configuration to a map, because a map may already have discarded duplicate definitions. Resolve duplicates according to the intended value and check unusual quotes or spaces against the application loader. Use env-file-validator for another syntax review and compare the resulting key list with required keys. Tool validation does not prove precedence across process variables, mounted files and application defaults; verify the effective values in the test environment without exposing secrets.
Put staging and production blocks into environment-config-diff-visualizer using its named environment headers. Mark each difference as intended, corrected or still open. A production hostname may be expected; a missing database key or a leftover debug flag needs a decision. Attach Dockerfile findings, reference checks, duplicate resolutions and the classified diff to the same revision. Before approving deployment, attach actual CI build, pull and startup results as separate evidence. For configuration conversion or merging, continue with config-workflows; broader infrastructure identifier checks belong in network-infrastructure-identifier-format-checks.
Workflow playbook
Run static rules, inspect severity and line numbers, and review base pinning, user choice, package installation and embedded configuration findings.
Check base and application repository, registry, tag or digest syntax. Record the chosen reference without treating valid syntax as registry availability.
Parse sanitized dotenv text to expose duplicate keys and quote or space issues, then review syntax validation against the required-key checklist.
Compare staging and production blocks of the same revision, classify missing keys and changed values, and attach real CI build and startup evidence to the review.
Review line-level Dockerfile findings against the application's needs. Record the reason and owner for each retained warning instead of chasing a zero-warning score.
Validate the image reference syntax here; verify registry availability, image identity, pull permission and supported architecture separately in the deployment environment.
Classify hostnames, ports and feature flags against the agreed environment policy. Keep missing required keys and unexplained values open until resolved.