Components and architecture

[rorybyrne]

It's hard to suggest an architecture before we've nailed down exactly what problem the tool is trying to solve.

Some assumptions about what the components and architecture will need to achieve:

• Glance should in some way aggregate information from multiple repositories
• Glance needs to infer some facts about the topology of the repositories (e.g. branch naming schemes)
• Glance needs to know which aggregations are valuable to the user. Perhaps the user can specify this via the CLI.

[deknos]

Hi, i was redirected here for the communication from https://old.reddit.com/r/programming/comments/hhh5ze/glance_a_proposed_cli_tool_which_shows_useful/

First i have to say, i work in a project where we have many repositories which we have to manage. ranging from azure functions, over containers, mobile apps until repositories which describe VMs. In Summary it's over 70 repositories. some are microservices, some infrastructure stuff (infrastructural k8s packages) is managed grouped together in one repository. Therefore my POV might be a bit different than yours. But my pain points for managing multiple repositories would be the following:

• i want a machine readable way of seeing which repositories contain what.
• if it is a microservice, i want to know its development flow (like git flow or github flow, trunk based development?) but not via tag, but via:
  • show/describe the deployment branches or tags like deployment_branches = [master, oldstable]
  • show/describe the release branches and/or tags releases = [branches : [ v0.1, v0.2, .. , v1.0 ] ] or releases : tags { v01 : 20200503 , v02 : 20200609 , v03 : someotherdate }
  • show/describe the development branches like development_branches = [ develop, sprint13, sprint12, ..]
• describe the script which tests for environment and tries to build an build/runtime environment, like build_environment_script = GITDIR/bin/create_env
• describe the script which builds the only or multiple binaries/packages which this repositories is for
• describe which directories are for build_artefacts but should be empty.
• show the dependencies either based on artefacts with FQDNs or Repositories via relative path or FQDN, like dependencies = [ common_functions : ../common_functions, helper_scripts: https://github.com/foobarsnafu/myhelpers ]

There are more possibilities, but that's a starter. Normally i would say this file should be in json and we should agree on some key terms/a small specification. the file should be either in master, or if it is not in master itself, the file in master should reference the place via giturl/relativepath/fqdn like description_origin = https://github.com/superbigproject/servicedefinitions/myownrepository.json and in there the file should be named like the git repository.

Then you can either decide having the stuff in its own repository all together, OR have a description.json in each repository..

The KEY point is: if it is json (or yaml) we can just automatically decide over all repository and list their (technical, business) dependencies independent from their language or deployment destination/techstack.

This would ALSO make it easier for CICD pipelines to interoperate and reason over a couple of repository which create a system.

and since the description is managed in GIT you also can see its changes, perhaps versioning, or list for all your repositories their last 5 releases.

i am less about good terminal visualization and more about rapid requests like the "last 5 releases" or better automation for CICD pipelines, and for that, such files could massively help

[rorybyrne]

Hey @deknos thanks for the detailed write-up. Like I said before, I think the idea of a file containing meta-info about the repository is great - perhaps it would be called Metafile?

It seems clear that the Metafile will have uses far beyond this particular tool, so it should be designed carefully and ideally with people from as many different backgrounds as possible weighing in.

I'm building this tool for myself, first and foremost, so it will attempt to make the developer's life easier on the command line by giving visibility into groups of repos. The first 5 points you mentioned will be relevant for that kind of functionality.

The later points are more geared towards automation. That kind of functionality probably won't be a part of this tool, but we should certainly keep it in mind when designing a spec for the Metafile so that others can build useful things.

[rorybyrne]

Possible directory structure:

src
├── main.py
└── render
    ├── grid.py
    └── components
        └── box.py
└── view
    ├── base.py
    └── view.py
└── git
    ├── base.py
    └── github.py
└── cli
    ├── entry.py
    └── commands
        └── run.py

Architecture

cli/ Command-line entry point and commands.

git/ Model of GitHub repositories. Should be easy to extend to support other git platforms.

view/ Models aggregations of meta-information about groups of repositories. This layer should contain business logic and use the render layer to do the actual rendering.

render/ Components and layout rendering on the command-line. Uses Rich.