tendermint / testnets

Config files for connecting to testnets
17 stars 19 forks source link

move testnet files to respective repos #13

Open zramsay opened 6 years ago

zramsay commented 6 years ago

from Slack discussion, we should simplify things because every testnet connecting tutorial has

git clone thisREPO
cd thisREPO
gaia/ethermint init

when instead the testnet files could be in the respective repo

This issue would actually lead to deprecating this repo, which is not a bad thing

adrianbrink commented 6 years ago

I massively in favour. After writing a simple blog posts on how to get started with running our software stack I now realise that it is not easy if you are not doing it daily.

https://blog.cosmos.network/connecting-to-the-latest-cosmos-hub-network-gaia-2-57568e2d6b9

greg-szabo commented 6 years ago

Current repos where this would be interesting is gaia, ethermint and basecoin. So, what you're saying is that you have no problem for an automated system (Jenkins in the current case) to have direct push privileges to your source repository.

Also, this would immediately invalidate any discussions about forced pushes and those would be outlawed as automation is not supposed to do them and automation can't do proper updates if others do them.

I don't see how it would go over, if we co-sourced our "sacred" source-code and the "oily" moving bits of an automated system that looks different every day.

I would be open to such idea if we change are our thinking about repositories. In an automated deployment world, the source code and the deployment method is usually coupled: The source respository contains Jenkinsfile, to describe the Jenkins job that runs the CI/CD automation, it contains, pom.xml for automated Maven jobs or in our case decent Makefiles that support automation properly. Right now, anytime I wanted to improve something on the Makefile to make it even compatible with the build process, I ran into developer walls, because developers want to do it differently on their local machines.

So I'm building automation separately from our source code. It's not an ideal scenario, but for now it works. I consider introducing high-level moving parts of this automation into the source code repository without ever agreeing on the low-level, crucial part of that same automation an ugly hack.

nickray commented 6 years ago

Related: https://github.com/tendermint/testnets/pull/41 I think it's useful to have a central (if inofficial) reference of known "already used" chain IDs. I do also think chain IDs should be UUIDs instead of short strings, but that's a different discussion :)