rohitkochhar / talbot

Quick and easy scaffolding for Go microservices

talbot

Quick and easy scaffolding for go servers and microservices

Installation

Building from source

To build talbot from source, select the proper GOOS and GOARCH for your platform and use the following instructions:

$ git clone [email protected]:RohitKochhar/talbot.git
$ cd talbot
$ GOOS={darwin,linux,windows} GOARCH={amd64,arm64} go build
$ mv talbot /usr/local/bin

Usage

Usage:
  talbot make [flags]

Aliases:
  make, m

Flags:
  -n, --app-name string   Name of application (Required)
  -d, --dir string        Path to target app directory (default "./")
  -h, --help              help for make
  -m, --mod-name string   Name of top-level application go module (default $app-name)

Example

Running:

$ talbot make -n example-output -d . -m github.com/rohitkochhar/talbot-output

Generates the application seen in this repository's ./example-output directory.

Contributing

For information on contributing to this project, please see CONTRIBUTING.md

talbot's Issues

`skeleton-files` directory not compiled into binary

Currently, if the binary is built using the instructions outlined in the README.md, running talbot make will execute correctly up to the file templating (which is the important part)

This is because the TemplateFile function in helpers.go:102 looks in a provided file path and reads the file directly, but once the binary is built and the command is executed outside the repository directory, it can no longer locate these files.

The solution to this is to read the skeleton-files at an earlier point in the program execution and save the contents as variables. This will allow the content to be baked into the binary executable, so the file reading will not be needed. However, this will come at a cost of increase executable size.

Run `go-lint` or `gofmt` on files after templating

Automatically merge PRs created by `deploy` action

Currently, the deploy action commits onto the deploy branch since the main branch is protected. Therefore, every time something is tagged, the PR has to be manually made and merged, which isn't ideal.

To avoid removing branch protection on main, there must be a way to automatically merge PRs from deploy or allow deploy to auto-commit to main.

Allow multi-service definition via YAML

Add functionality that would allow multiple microservices to be defined from a single YAML. For example, a YAML file like:

serverName: project_name
parentDirectory: ./project
microservices:
  - appName: microservice-1
     childDirectory: microservice_1
     endpoints:
       - path: /v1/healthcheck
          method: GET
          desc: "Something"
   - appName: microservice-2
      childDirectory: microservice_2
      endpoints:
       - path: /v1/healthcheck
          method: GET
          desc: "Something"

Should create two microservices in paths of ./project/microservice_1 and ./project/microservice_2, and the docker-compose.yaml should be located at the top-level of project and include the images built from the Dockerfiles in the microservice directories.

Add tests for talbot

No code coverage atm :( Unit tests and integration tests need to be added to the talbot command functions.

Check that commits match Conventionial Commits pattern

The CHANGELOG.md updating that is done by deploy action requires that commit messages follow the pattern outlined here.

To prevent bad commits from making it to this step, an action should be implemented that ensures that only good commits are merged.

Implement auto-release GitHub actions

Rather than manually issuing releases, semantic version should be implemented and enforced, and builds should be automatically published as releases as outlined here:

https://github.com/marketplace/actions/auto-release

Allow additional YAML configuration

To allow for more flexible scaffolding, users should be able to provide a YAML file containing certain configuration settings for their scaffolding app. If a YAML file is provided, no other flags should be needed, that is, the YAML should be able to provide all the information previously accepted by the flags

The YAML file should be accepted by the program like:

talbot make -c conf.yaml

The YAML could look something like this:

name: app_name
mod_name: module_name
directory: relative directory
endpoints:
  - path: /v1/healthcheck
     method: GET
     description: "some description"
  - path: /v1/upload
     method: PUT
     description: "some description"

The program should then configure the app like normal, template the router to connect the endpoints to their specific handler functions and update the README to contain the information on the endpoints