Improvement suggestions for guild operators scripts

[tomdx]

IMHO there still is some room for improvement with these commonly used scripts …

• guild-operators does not have releases nor stable tags that can be associated with the latest iohk node version
• default branch is ‘alpha’. new installations always fetch an arbitrary commit that happens to be HEAD on an alpha branch
• topologyUpdater seems to fetch an arbitrary new version every hour and then ask for user consent

this could perhaps be improved by …

• use milestones, tags and (regular) releases
• have a ‘stable’ branch that the next tag is cut from
• all fast innovation can happen in some dev or alpha branch, that should however never be the source for node installations
• updates should only happen at build/update time (on explicit user request) never at runtime
• updates should go from one well known tag to the next

[rdlrt]

Thanks for the suggestions. For starters, not many guild members are active on forum - would be nice to have any suggestions/recommendations on github (it has discussions enabled). But since there is quite some confusion / misinformation in your post, I would like to comment on them here.

@tomdx

does not have releases nor stable tags that can be associated with the latest iohk node version

There are multiple tools with seperate version numbers. These tools may or may not necessarily rely on a node version. There are tags against specific node versions mainly for compatibility.

@tomdx

default branch is ‘alpha’. new installations always fetch an arbitrary commit that happens to be HEAD on an alpha branch

Not sure where you get that from, the entry point for most of the scripts is via master. alpha is default branch for submitting any PR. After a change is tested for a while on alpha branch, it’s merged to master.

@tomdx

topologyUpdater seems to fetch an arbitrary new version every hour and then ask for user consent

That’s a user option and fetch is not required hourly, but upon restart of node (push to notify your relay is live is done hourly).

@tomdx

use milestones, tags and (regular) releases

Again, there are tags, but individual components (gLiveView, CNTools, cncli.sh, etc) may have different versions which for which github releases do not make sense.

@tomdx

have a ‘stable’ branch that the next tag is cut from

Tag is always cut from master branch, so this is already the case

@tomdx

all fast innovation can happen in some dev or alpha branch, that should however never be the source for node installations

It is only the source for advanced users who elect to use alpha branch, from the entry point, viz, prereqs.sh. This is well-documented on the portal.

@tomdx

• updates should only happen at build/update time (on explicit user request) never at runtime
• updates should go from one well known tag to the next

Updates occur via prompt to users. There are multiple moving parts/combinations:

• the common env file is unattached to other scripts, and user is prompted when there is an update
• gLiveView/CNTools/etc are marked with release, and updated accordingly. github tags do not make sense for these since many of these are independent.

I understand that you’re not familiar with the repository and maybe missed to check guides beyond WIP docker images, but I invite you to share any concerns/follow-ups to github discussions

Also, one last thing that I’d like to mention (it is in docs but just to clarify) - the ‘guild’ is essentially any community member who would like to help contribute by working closesly against that repository, it is not exclusive to subset of folks - there’s a reason why it’s part of cardano-community umbrella (which also hosts support-faq, concepts, cswg, etc)