Add opt-in Compose toolchain provisioning and preflight

Aperta
  • Qualcosa non va?
#3,523 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
aws, docker, docker-compose
Ambito
devops, infrastructure

Direzione di ricerca

Start with prerequisite #3509 and related spike #2763, then locate the EC2 and AWS Marketplace provisioning paths. Check how each installs Compose and how deployed scripts invoke it. Done means both paths meet the pinned, verified toolchain contract and the acceptance criteria, with adoption and rollback documented without changing non-adopting hosts.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Related spike: https://github.com/openremote/core/issues/2763

Prerequisites / integration: #3509.

User Story

As a deployment maintainer, I want opt-in, reproducible Compose provisioning and preflight so that bundle deployments use a tested toolchain without forcing upgrades on existing hosts.

Description

Provide a reproducible, tested Compose installation for hosts that opt into the new bundle workflow. Separate this from CI's validation pin and from upgrading the installed binary on existing hosts.

Both EC2 provisioning and the AWS marketplace currently download an unbounded latest standalone docker-compose binary. Add a version/checksum/architecture contract and an explicit adoption path. Preserve the executable form expected by deployed scripts; a plugin-only installation must not break callers of docker-compose.

Acceptance Criteria

  • Selected CLI/Engine versions and required features are checked before any stack shutdown.
  • Installation uses a pinned release and verified artifact for supported host architectures; equivalent plugin and standalone command use is documented and tested.
  • Existing deployments are not upgraded or subjected to the new bundle minimum merely by merging preparation changes. A non-adopting host needs no new variable.
  • Both provisioning paths and existing-host upgrades are covered; rollback of the CLI selection is documented separately from application/database recovery.
  • Legacy single-file startup and new include/override/one-shot compositions pass on the chosen version before the host adopts it.
  • Balena retains its separate tooling and syntax contract.

Implementation Notes

  • Keep the CI validation pin separate from production host adoption.
  • Cover both EC2 and AWS marketplace provisioning, supported architectures, artifact verification and the executable forms expected by deployed scripts.
  • Use synthetic examples and isolated fixtures without customer identifiers or production secrets.
Lingua principale
Java
Stelle
1.9k
Fork
478
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openremote/openremote

Tutte le issue di openremote/openremote

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.