Force BuildKit to output in a text log friendly format when running in CI.

Note: due to #3, changes introduced in this PR won't be taken into account until they reach dev or main branches. :shrug:

:muscle: My Motivation:

BuildKit should automatically adapt progress output format based on environment. Unfortunately something doesn't play well with CircleCI and the produced output - while great for TTY - is terrible for text logs, leading to thousands of garbage lines in CircleCI's job logs. We want CI job logs to be usable, not filled with garbage.

:brain: My Solution:

Based on Docker CLI doc and CircleCI built-in env variables doc, use BUILDKIT_PROGRESS=plain env variable when CI variable is set in the environment to force BuildKit output in a text log friendly format. CI seems to be an env variable commonly set by other CI providers (ex: GitLab, GitHub, Travis) for portability.

Add code coverage measurement with results (HTML, LCOV):

• available locally to developer
• stored as build artifact by CI (only HTML report)
• published to codecov.io by CI (only LCOV report)

Note: due to #3, changes introduced in this PR won't be taken into account until they reach dev or main branches. :shrug:

:muscle: My Motivation:

Writing tests is essential to develop quality software. However, without code coverage the degree to which source code is executed by the test suite can't be really known. Adding code coverage enables to monitor the risk of introducing code with undetected software defects, and to enhance the test suite for code already in the codebase.

:brain: My Solution:

• make coverage use code instrumentation stabilized in rustc 1.61 to perform source-based coverage even accurate at branch level.

• Code instrumentation requires additional compilation flags which are set leveraging current dev container. Profiling is performed by executing the test suite on resulting instrumented build artifacts.

• grcov process resulting profiling files to produce reports in HTML and LCOV formats in .coverage directory at project's root.

This design allows producing those coverage reports without "polluting" the env with profiling artifacts, while making them available to developer and CI jobs for further processing.

Coverage measurements with defined settings seems to produce rather accurate results. Some derive macros and other logging statements needs to be further investigated for potentially additional tweaking.

Use 'medium' resource class for pre-checks as this is where most heavy compilation work happens, yet the gain from using 'large' is not enough at this state of the project.

CPU usage saturation during pre-checks (fresh cache) with:

• 'large' : 15sec/1min45 (14%),
• 'medium': 60sec/2min30 (40%). ('small' would has better saturation but total time would exceed 5min)

Use 'small' resource class for build-native as with 'medium' CPU usage barely reach 50%, and with 'small' 100% is achieved but during only a very short amount of time (<15sec).

Fixes: #1

:monocle_face: Bug I observed:

When using a RETURNING PostgreSQL clause in a statement, sqlparser-rs which is used to build the Query AST fails:

Err(ParserError("Expected end of statement, found: RETURNING"))

And since the Query AST can't be built, Fern proxy fails processing the query, which therefore isn't passed down to proxied Datastore.

:smiley: Behavior I expected:

Instead, I would expect the Query AST to be built as with any other statements not containing a RETURNING clause.

:gift: Something I'd like to add:

Issue is known already: sqlparser-rs/sqlparser-rs#60

:exploding_head: Problem I want to solve:

When collaborating on a project, it is important to ensure contribution guidelines defined for said project are being followed. Manually checking each contribution for compliance with project guidelines may become exhaustive, and become a source of frustration both for contributors and reviewers. Having the fastest possible feedback loop for commit linting is crucial for a pleasant experience.

:smiley: Solution I would like:

For this problem, I would like to:

• enforce Fern project's Conventional Commits guidelines in CI, for all branches / pull requests
• be able for developer - i.e. opt-in usage - to locally check if commit / branch is OK with guidelines prior pushing it to a remote branch, should they want a great DX / short feedback loop
• be as non-invasive of developer's env as possible, leveraging our Gazr / containers setup as much as possible
• provide interactive guidance if wanted by developer to easily write commit messages aligned with project's guidelines

:thinking: Alternatives I've considered:

Honestly none, I'm quite opinionated on the Developer Experience (DX) expectations for this one. :sweat_smile:

:gift: Something I'd like to add:

Some example resources worth looking at:

• https://commitlint.js.org/
• https://commitizen.github.io/cz-cli/
• https://circleci.com/developer/orbs/orb/conventional-changelog/commitlint

:monocle_face: Bug I observed:

When using GitHub's Rebase and Merge feature to keep a linear history, original commits' crypto signatures are dismissed.

:smiley: Behavior I expected:

Instead, given an up-to-date branch (enforced by settings) with crypto signed commits, I would expect to have those crypto signatures preserved when using GitHub's Rebase and Merge feature on a pull request.

:gift: Something I'd like to add:

Seems to be a known problem, apparently already notified to GitHub's engineering team:

• https://github.com/community/community/discussions/10410
• https://github.com/orgs/community/discussions/5524

:hourglass_flowing_sand: As the issue is directly with the GitHub's Rebase and Merge feature, either a different merging strategy must be used, or it should be accepted to have those crypto signatures dismissed until GitHub have it fixed.

:monocle_face: Bug I observed:

When making PR #2, related CI execution didn't trigger the build-container step, and actually even completely skipped a CI run, pointing to checks performed on the ci-circleci branch prior to PR to dev.

:smiley: Behavior I expected:

Instead, I would expect to see the pipeline workflow involving build-container on a PR to dev, so merge can be done with confidence.

:gift: Something I'd like to add:

Fixing the typo in build-container step was easy, but pushing code directly to dev while trying to introduce a proper Gitflow wasn't great. In the future, would be great to have a specific workflow to test changes introduced specifically on Makefile, Dockerfile, etc.