🦄 arcadia: Go template for Cobra based cli applications

🔰 Introduction

This project is a template to aid in the startup of Go cli applications.

📚 Usage

🎀 Features

• unit testing with Ginkgo/Gomega
• implemented with 🐍 Cobra cli framework, assisted by 🐲 Cobrass
• i18n with go-i18n
• linting configuration and pre-commit hooks, (see: linting-golang).

🔨 Developer Info

By using this template, there is no need to use the cobra-cli to scaffold your application as this has been done already. It should be noted that the structure that is generated by the cobra-cli has been significantly changed in this template, mainly to remove use of the init() function and to minimise use of package level global variables. For a rationale, see go-without-package-scoped-variables.

📝 Checklist of required changes

The following is list of actions that must be performed before using this template. Most of the changes concern changing the name Arcadia to the name of the new application. As the template is instantiated from github, the new name will automatically replace the top level directory name, that being arcadia. However, there are 2 situations at hand:

1. target repo is owned by the snivilised organisation: the changes required will be made automatically after the repo has been created from the template WITHOUT user intervention

2. target repo is NOT owned by snivilised, therefore user action is required after being cloned. Follow this sequence of steps:

• after cloning the repo, run the task, autocheck:

  $ task autocheck

This will result in various changes being made to the project. If you are using the pull-request model, then please make sure that you are on a feature branch before running the autocheck task. You can then check-in, then push the changes as per normal:

$ git add .
$ git commit -m "chore: initialise repository from template"
$ git push

➕ The following descriptions use owner name pandora and repo name maestro as an example. That is to say the client has instantiated arcadia template into github at url github.com/pandora/maestro

🤖 Automated changes

Automated via ./scripts/automate-checklist.go script. This is invoked by the autocheck task. You can look at the contents of this file, before running the autocheck task, doing so, you'll gain an understanding of the changes that will be implemented, if you're so inclined. After the task is run, this go script will be deleted.

🖐 Manual changes

The following documents manual changes required. Manual checklist:

☑️ Structural changes

• github actions workflow: If the client does not to use github actions workflow automation, then these files (ci-workflow, release-workflow, .goreleaser.yaml), should be deleted.

• rename the widget command: rename widget-cmd.go and its associated test widget_test.go to whatever is the first command to be implemented in the application. The widget command can serve as a template as to how to define a new command, without having to start from scratch. It will be easier for the user to modify an existing command, so just perform a case sensitive search and replace for widget/Widget and replace with Foo/foo where foo represents the new command to be created.

• review bootstrap.go: this will need to be modified to invoke creation of any custom commands. The execute method of bootstrap should be modified to invoke command builder. Refer to the widget command to see how this is done.

☑️ Taskfile change

• Remove the autocheck task from Taskfile.yml

☑️ Github changes

Unfortunately, github doesn't copy over the template project's settings to the client project, so these changes must be made manually:

Under Protect matching branches

• Require a pull request before merging ✅ ENABLE
• Require linear history ✅ ENABLE
• Do not allow bypassing the above settings ✅ ENABLE

Of course, its up to the user what settings they use in their repo, these are just recommended as a matter of good practice.

☑️ Code coverage

• coveralls.io: add maestro project

☑️ Miscellaneous changes

• replace README content
• update email address in copyright statement: The root.go file contains a placeholder for an email address, update this comment accordingly.
• create .env file: Add any appropriate secrets to a newly created .env in the root directory and to enable the deploy task to work, define a DEPLOY_TO entry that defines where builds should be deployed to for testing
• install pre-commit hooks: just run pre-commit install
• update translation file: Inside Taskfile.yml, add support for loading any translations that the app will support. By default, it deploys a translation file for en-US so this needs to be updated as appropriate.

🌐 l10n Translations

This template has been setup to support localisation. The default language is en-GB with support for en-US. There is a translation file for en-US defined as locale/i18n/deploy/arcadia.active.en-US.json. This is the initial translation for en-US that should be deployed with the app.

Make sure that the go-i18n package has been installed so that it can be invoked as cli, see go-i18n for installation instructions.

To maintain localisation of the application, the user must take care to implement all steps to ensure translate-ability of all user facing messages. Whenever there is a need to add/change user facing messages including error messages, to maintain this state, the user must:

• define template struct (xxxTemplData) in locale/i18n/messages.go and corresponding Message() method. All messages are defined here in the same location, simplifying the message extraction process as all extractable strings occur at the same place. Please see go-i18n for all translation/pluralisation options and other regional sensitive content.

For more detailed workflow instructions relating to i18n, please see i18n README

🧪 Quick Test

To check the app is working (as opposed to running the unit tests), build and deploy:

task tbd

(which performs a test, build then deploy)

NB: the deploy task has been set up for windows by default, but can be changed at will.

Check that the executable and the US language file maestro.active.en-US.json have both been deployed. Then invoke the widget command with something like

maestro widget -p "P?<date>" -t 30

Optionally, the user can also specify the directory flag:

maestro widget -p "P?<date>" -t 30 -d foo-bar.txt

... where foo-bar.txt should be replaced with a file that actually exists.

This assumes that the the project name is maestro, change as appropriate.

Since the widget command uses Cobrass option validation to check that the file specified exists, the app will fail if the file does not exist. This serves as an example of how to implement option validation with Cobrass.