Keep quickstart:future in sync with futurenet's automated deployments
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
Start by locating the quickstart build and image update automation, then trace how futurenet deployments expose the Core, Horizon, RPC, and Galexie commit SHAs. The issue leaves where those SHAs should be recorded undecided, so first investigate deployment metadata and discuss an approach with the maintainers. Done means quickstart can build from the matching source refs and automatically open an update PR.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What problem does your feature solve?
Futurenet is now deployed automatically on a regular cadence from development versions of software targeting the next protocol.
The quickstart:future image is meant to track what runs on futurenet, but right now nothing keeps it in step with these automated deployments. In the past it was updated manually when futurenet was deployed.
Unless someone updates it by hand, quickstart:future will fall behind futurenet.
Developers testing locally against future could then hit protocol or software behaviour that differs from the network.
What would you like to see?
quickstart:future automatically follow the same Core, Horizon, RPC, Galexie versions that are deployed to futurenet, without quickstart using the binaries or images that the internal pipelines build.
Quickstart keeps building from source as it does today, but it needs a way to find out which commit SHAs futurenet is running and then automatically trigger a PR updating the image.
That suggests there needs to be some place that records the commit SHAs in each futurenet deployment, which quickstart could read to know which refs to build. I'm not sure where that should live yet.
cc @sisuresh @jacekn @stellar/devx
- Lingua principale
- Shell
- Stelle
- 225
- Fork
- 236
- Merge medio
- 2g 7h
- PR unite (30g)
- 15
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di stellar/quickstart
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
stellar/quickstart#1013 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
feature request
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
stellar/quickstart#998 · 5 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
DockerHub README workflow fails with 403 ForbiddenForse di nuovo libera @leighmcculloch l’ha presa 45 giorni fa e non c’è nessuna pull request aperta. Apertabug
stellar/quickstart#988 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
stellar/quickstart#932 · 18 commenti · 2 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
stellar/quickstart#923 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di stellar/quickstart
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Watchdog webhook body emptyApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
mailcow/mailcow-dockerized#7651 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
mohi-devhub/antivibe#12 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
awsdocs/amazon-eks-user-guide#1261 ·