Create GitHub Actions workflows

[krashish8]

Create GitHub Actions workflows script for:

• Build
• Test
• Style check
• Releases
• Code coverage (?)

[dkastl]

Do we need a build matrix?

[krashish8]

Yes, build matrix can be used for building it using different Golang versions, or on different OS like ubuntu, windows, and macOS.

I think normally, building on a different OS will be helpful only for releases so that a separate executable is created for each OS. For now, we can use only ubuntu, because I haven't figured out yet how to build vrprouting on windows/macos. Building with different Go versions is definitely a good idea.

[dkastl]

Well, a multi-dimensional matrix can grow big very quickly.
I think testing with the following could be good:

• PostgreSQL/PostGIS versions
• (maybe Golang versions)

I think we leave OSX and Windows up to those, who feel motivated to contribute this ;-)

[krashish8]

Added GitHub actions:

• Test: Build & Test, and to get the test coverage.
• Lint: Checks go modules are up-to-date (go mod tidy), Lints Go code using golangci-lint, Checks license (licensecheck) and shell scripts (shellcheck).
• CodeQL: CodeQL GitHub analysis to find common vulnerabilities in the code, and get alerts here: https://github.com/Georepublic/pg_scheduleserv/security/code-scanning

Pending GitHub Actions:

• Releases.

Not using build matrix. Since we started with Go 1.17, this will support only Go 1.17 and above, so no need to test previous versions. Not testing with PostgreSQL or PostGIS versions, because that is already done in vrprouting. This is just an application layer on top of vrprouting, so if vrprouting is tested with PostgreSQL versions, then this will also work.

[krashish8]

The Test action can also upload the coverage result to codecov, where anyone can see the code coverage of all the tests, which lines of which files are covered (and not covered) by the tests, in the Codecov GUI.

This step of the Actions tries to upload results to codecov: https://github.com/Georepublic/pg_scheduleserv/runs/4448243963?check_suite_focus=true#step:18:35

However, we haven't enabled codecov yet, so this does not work. Is it okay to enable codecov for pg_scheduleserv?
It is free for open source projects, but to enable, codecov will require access to Georepublic GitHub.

Sample example of how Codecov coverage would look (a different repository in Golang): https://app.codecov.io/gh/go-openapi/runtime/

[dkastl]

I granted permissions to Codecov, started the setup of the repository, added the secret variable in the repository settings and re-run the test action. It seems to work: https://app.codecov.io/gh/Georepublic/pg_scheduleserv/

If you login to Codevov you should be automatically granted access to the project.

[krashish8]

Thanks! It is giving the coverage for one of the old commits, but I'll fix that.

[dkastl]

OK, I probably only understand partly what it does ... but the graphs look nice ;-)
If you want this for pgRouting organisation as well, let me know.

[dkastl]

Now I can see better coverage stats. The nice thing is, that it now shows a difference, because I run the test before that was 2 days old. So it was a good "mistake" ;-)

[krashish8]

Yes :)

For pgRouting, I don't think this can be done now, or maybe it will be not very beneficial now. First, we will need to find some code coverage tools for pgTAP. Secondly, because we only write the pgTAP tests, which is similar to black-box testing of the extension, any coverage tool would report only the SQL code coverage.

Our main logic of pgRouting lies in the C++ code, and we don't test the C++ code directly, but the entire SQL function, so maybe it's not straightforward to do this now. :)