Additional Tooling

[jtcarnes]

@foltik glad to get a chance to do some work on the provider. There are a few things I wanted to ask about first before I work on the resources (as if affects their development) and some additional tooling:

1. Linting

• Currently the repo doesn't have any linter specified. Most go projects use golangci-lint or something similar. Would it be ok to add:
  • a baseline golangci-lint config to the repo
  • a CI workflow for testing and linting

2. License. The repo currently does not have a license. The hashicorp provider scaffold uses Mozilla v2.
3. Automatic Versioning
   goreleaser is fantastic for generating outputs and releases on git tags, however it does not generate a tag itself. Currently, you have to manually tag a git commit then run goreleaser. One tool I've used in several projects to help with this is semantic release. Semantic release helps by analyzing the commits and generating a new tag based on the changes. Go releaser has an official documentation on how these two work together here.

Including it will help automatically create appropriate versions without manual intervention, as well as do a few useful things like update changelogs, etc. To make it effective however, you need to use one of a few commit formats so it can properly understand whats going on. I normally use conventional commits.

The benefits are automatic versioning and changlogs while integrating with goreleaser. If this is of interest I could:

• create a semantic release config
• add semantic release to the release ci
• Add notes in the readme and a CONTRIBUTING about the use of conventional commits

4a. Testing

Currently the provider doesn't have any testing but we will be adding some shortly (that is an issue on its own). Currently, the CI does not perform any testing even when its added.

I would like to: add a CI job to run golang testing. An example can be seen in terraforms scaffold provider here

4b. Coverage report

Once we add testing, it'll be difficult to know in MR what has coverage and what doesn't. Go has built in line coverage with -cover and there are a number of tools to make line coverage a part of the MR process. The most common tool (that's free for open source projects like this one) is codecov, but there are several available.

I would like to: add a code coverage tool to the build and MR process to check that new code is covered in at least one test.

[foltik]

Thanks for the proposals @jtcarnes! Regarding each:

1. Linting - definitely!
2. License - just added the MIT license.
3. Automatic Versioning - I'm hesitant to give up the additional control of manual versioning, but the benefits seem worth it. Willing to give conventional commits and semantic release a shot! If it works well, I'll adopt it in vyos-client-go as well.
4. Testing/Coverage - #4 is still a work in progress, but pure go testing and coverage along with the linting in CI would be a welcome start.