feature: Initial migration to golang

[mrlunchbox777]

Contact Details

mrlunchbox777@gmail.com

Feature Description

Prepare a golang CLI app that will be where the majority of the bash scripts will migrate to.

Why?

golang will reduce the amount of boiler plate code that the bash scripts currently have. It will also standardize how arguments are handled, help documentation is generated, and more. It makes code more maintainable and more reusable. Also doing it this way allows this to be a backwards compatible, incremental conversion.

What-should happen?

A new golang project should be created in a directory called bsctl/. This project should be a CLI application called bsctl. It should be abstracted enough to facilitate testing and modular replacement of packages as needed, i.e. using factories. It should maintain >80% test coverage from the start. Pipelines should be built to run tests, builds, releases, formatting checks, linting checks, and documentation bump checks. It should have a Makefile that supports standard development needs, e.g. build, test, coverage, etc. It should support versioning and a CHANGELOG. It should include documentation specific for developers and consumers of the application.

Steps to Test

• A CHANGELOG in the root
• A folder called bsctl/ in the root
  • A golang CLI application in this folder
  • A documentation folder that contains developer and consumer specific documentation
  • The CLI modules should be small wrappers around abstracted modular code (factories)
  • The application should have >80% coverage
  • The application should follow go vet and golangci-lint standards
  • The application should follow go fmt formatting
  • The application should support versioning
• A Makefile in the root
  • It should support basic development needs
  • build
  • test
  • coverage
  • install
  • run
  • format
  • lint (for both linters)
  • clean
  • It should run for both bash and go, as much as possible and applicable

Covers this TODO, this TODO, and this TODO

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[mrlunchbox777]

when working this issue we need to move these variables to the new configuration file implementation - the TODO

[mrlunchbox777]

we should check this issue for comments about TODO's removed by this migration and ensure that they are actually resolved.

[mrlunchbox777]

When creating the new issues for migrating functionality ensure to include verbosity. Covers this TODO.

Also these:

• validation: add verbose and push this out
• validation: add a flag to make all of this optional (or maybe optional by default)
• this should probably be discarded validation: add a check that ensures this is checked at generalrc
• talking about package managers validation: do the tooling checks as well (maybe as part of the tooling)
• tooling: offer an interactive way to update here

[mrlunchbox777]

closed this accidentally

[mrlunchbox777]

done