Setup CI using Github Actions

[cuminandpaprika]

Setup Continuous Integration on this repo.

Requirements

• [x] Linting
  • Golangci-lint can be run several ways, either via reviewdog or codeclimate to get comments on the PR. Or it can be run directly as a check.
• [ ] Code Analysis
  • SonarCloud https://sonarcloud.io/dashboard?id=cuminandpaprika_sysl-go-comms
• [x] Run tests
• [x] Check Test coverage
• [x] Check go mod tidy doesn't modify any files
  • Something like https://blog.urth.org/2019/08/13/testing-go-mod-tidiness-in-ci/

Stretch Goals

• Spell check commit messages https://github.com/marketplace/actions/check-spelling
• Run and deploy example repo for preview, e.g https://zeit.co/github#features or heroku
• Automated Release Tagging Blocked till https://github.com/anz-bank/sysl/issues/666 is closed
• Validate transform files with sysl validate
• Validate makefile keeps git state in porcelain state

[cuminandpaprika]

Investigations into Coveralls seem to prove that Go support is secondary, and documentation seems to be outdated. Refer to https://docs.coveralls.io/go

• Go support is user contributed and the docs are for an older version of Github Actions

Running with the following config

    - name: Publish test results to Coveralls
      uses: coverallsapp/github-action@v1.0.1
      with: 
        github-token: ${{ secrets.github_token }}
        path-to-lcov: ./coverage.out

Produced these results:

[error] "2020-03-17T07:21:37.830Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2020-03-17T07:21:37.830Z"  'input: ' 'mode: set\n' +

https://github.com/cuminandpaprika/sysl-go-comms/pull/1/checks?check_run_id=513083763

[cuminandpaprika]

Comparisons of SonarCloud Scanning methods:

• SonarCloud Automated Scanning docs
  • Doesn't do code coverage
• Github Action
  • Github Action is slightly flakey when posting results. example on a push that should've had no impact on SonarCloud's config.
  • Enables Code Coverage
  • Takes an extra 98 seconds to run sonarcube, taken from here

As a result, I'm leaning towards the use of SonarCloud's Automated Scanning feature.

[juliaogris]

You know, I don't really think you need to worry about coveralls or codecov - really these are just pretty pictures on top of running coverage. When coverage target is not met you need to investigate locally anyway.

Here's a makefile snippet from vcards (courtesy @camh-anz ) that we have been using for coverage checks:

COVERFILE = coverage.out
COVERAGE = 98

test:  ## Run unit tests
    go test -coverprofile=$(COVERFILE) ./...

check-coverage: test  ## Check that test coverage meets the required level
    @go tool cover -func=$(COVERFILE) | $(CHECK_COVERAGE) || $(FAIL_COVERAGE)

cover: test  ## Show test coverage in your browser
    go tool cover -html=$(COVERFILE)

clean::
    rm -f $(COVERFILE)

CHECK_COVERAGE = awk -F '[ \t%]+' '/^total:/ && $$3 < $(COVERAGE) {exit 1}'
FAIL_COVERAGE = { echo '$(COLOUR_RED)FAIL - Coverage below $(COVERAGE)%$(COLOUR_NORMAL)'; exit 1; }

Been working pretty neatly.

Same for linting - imo command line will do

[cuminandpaprika]

Been experimenting with a way to check that go mod keeps it in a porcelain state but I've come to realize how barely competent I am at bash, let alone bash commands in makefiles

The idea is that we want to run go mod and make sure that no files are changed That way in CI, we can just run make check-tidy which has a non zero return code if the check failed.

One way I've found to do this is something like the below ()

Testing in zsh has produced the following results test -z "$(git status --porcelain)" followed by echo $? correctly returns 1 when there are uncommited changes.

Combining the two together would require something like go mod tidy | test -z "$(git status --porcelain)" which also correctly returns 1

WIP. More thoughts and ramblings to be continued

---

Now, to add it to the Makefile, we need to escape our $ with $$

check-tidy: ## Check go.mod and go.sum is tidy
    go mod tidy | test -z "$(git status --porcelain)" | exit $$?

[camscale]

You don't want to pipe one command into another. You want to use && to ensure both commands succeed:

go mod tidy && test -z "$(git status --porcelain)"

If go mod tidy fails, the whole command fails. If test -z fails, the whole command fails.

That is sufficient. You do not need the exit command - we just use the exit status of the commands we run.