andonly1348GitHubgoogle-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>andonly1348This commit establishes the authoritative standard for release artifacts and ensures rigorous validation during the packaging process. Key changes: - Refined `scripts/package_release.sh` with stricter validation gates, including a check for non-empty migration directories and automated checksum manifest generation. - Updated `docs/RELEASE_ARTIFACTS.md` to document the mandatory components of a valid release, including Docker metadata and optional research reports. - Synchronized packaging logic with `scripts/atlas_audit.py` governance requirements. - Verified artifact completeness and integrity via end-to-end manual testing. Artifact components now include: Docker image, metadata, .env template, database migrations, configuration reference, release notes, and a SHA256 checksum manifest. Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: andonly1348 <279141437+andonly1348@users.noreply.github.com>
3.0 KiB
Release Artifact Standards
This document establishes the authoritative standard for what constitutes a valid, deployable release artifact for the MT5 AI/ML Trading Bot. Compliance with this standard is mandatory for all production deployments.
1. Goal
The primary goal of artifact standardization is to ensure that every release is atomic, traceable, immutable, and verifiable. An artifact must contain everything required to deploy the system to a clean environment.
2. Mandatory Artifact Components
Every release package generated by scripts/package_release.sh must include the following components. The absence of any component renders the release invalid.
| Component | File/Format | Description |
|---|---|---|
| Docker Image | image.tar.gz |
A compressed tarball of the Docker image with the tagged version. |
| Docker Metadata | docker_info.json |
JSON metadata containing image name, tag, build date, and Git commit reference. |
| Environment Template | .env.example |
The authoritative template for all environment variables required by the specific version. |
| Database Migrations | migrations/ |
The directory containing all Alembic migration files required for schema updates. |
| Configuration Documentation | CONFIG_REFERENCE.md |
Auto-generated documentation of all configuration settings, types, and defaults. |
| Release Notes | RELEASE_NOTES.md |
Version-specific change log extracted from the main CHANGELOG.md. |
| Research Reports | research_*.md/html |
(Optional) Automated research verification and audit reports. |
| Checksum Manifest | checksums.sha256 |
SHA256 hashes of all files in the release for integrity verification. |
3. Artifact Directory Structure
Artifacts are organized in versioned directories:
releases/v<VERSION>/
├── image.tar.gz # Tagged Docker image tarball
├── docker_info.json # Metadata about the build (Git SHA, date)
├── .env.example # Configuration template
├── migrations/ # Database migration scripts
│ ├── versions/
│ └── ...
├── CONFIG_REFERENCE.md # Auto-generated configuration docs
├── RELEASE_NOTES.md # Version-specific release notes
└── checksums.sha256 # Integrity manifest
4. Validation
The scripts/package_release.sh script verifies artifact completeness before marking a release as deployable. It performs the following checks:
- Component Presence: Ensures all mandatory files and directories exist.
- Integrity Check: Generates and verifies SHA256 checksums for all included files.
- Version Sync: Confirms version consistency across metadata and source code.
- Environment Validation: Ensures
.env.exampleis complete and valid.
5. Integrity Verification
To verify a release artifact, run the following command within the release directory:
sha256sum -c checksums.sha256
Standard Owner: Jules03 (Release Reliability & Governance) Status: Mandatory