search

Atleta-network / atleta

GNU General Public License v3.0
7 stars 4 forks source link

Should we encapsulate deploy scripts into a dedicated repo? #121

Open ales-tsurko opened 2 weeks ago

ales-tsurko commented 2 weeks ago

Deploy becomes too complex and would be easier to work with in isolation, having it's own git log. In this repo we could concentrate on the nodes itself and configure it to release artefacts on Github Releases and Docker. The artifacts could be used by workflows in the deploy repo either automaticall (CD-fashion) or manually. Also, in case of a dedicated-to-deploy repo we don't need a workflow which separates branches related to different networks.

@hrls @DmitriVT what do you think?

hrls commented 2 weeks ago

I totally agree. External repo for deployment simplifies a lot of things. In current repo we can keep build scripts and artifacts for releases. New deploy repo uses these artifacts (or build from tag) to deploy the network. It also can contain chain specs and even docker related things.

DmitriVT commented 2 weeks ago

I concur that establishing a separate repository for deployment can streamline our workflow significantly. By isolating deployment, we can maintain a cleaner development environment in the main repository, focusing purely on node development and artifact creation. The new deployment repository would then handle these artifacts, whether pulling directly from releases or building from specific tags. This not only simplifies our version control by avoiding the need to manage multiple network-related branches in a single repository but also enhances our deployment flexibility. Including chain specifications and Docker configurations in this dedicated repository would further centralize our deployment processes, making them more straightforward and manageable.

ales-tsurko commented 2 weeks ago

Ok, moving it to Todo then. Thanks guys!

hrls commented 1 day ago

I found that sometimes we want to reveal devnet secrets to the dev team. In the new deploy repo we can works with secrets with all sort of paranoia. Then we can share secrets in this repo as it should keep only devnet related stuff. To be discussed.. as it requires high-level design of new workflow.