Open zramsay opened 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
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 Makefile
s 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.
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 :)
from Slack discussion, we should simplify things because every testnet connecting tutorial has
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