#2034 More rapid CircleCI builds (Part 1)

[raman-m]

Fixes #2034

• 2034

1st Part

This is the 1st part, the most substantial, of changes aimed at accelerating CI builds. The overall duration for PR workflows has been reduced by 3-4 times, from 12-13 minutes to 3-4 minutes. The actual duration varies based on CircleCI server load (daytime, working hours, nighttime).

View the latest CI builds here: raman-m/2034 and note the Duration column❗

2nd Part

The 2nd part will address aspects of:

• Test parallelism. Currently, only unit tests run in parallel.
• Workflow parallelism. This could shave off a few seconds.
• A review of the unit tests' "waiting" logic: thread blocks, wait times, timeout durations, etc. This is optional but could save some seconds.
• Docker architecture and images. We currently use a heavy Docker image with 3 pre-installed SDKs, which takes 15-20 seconds to download from Docker Hub. Enabling caching could save 10-15 seconds. Additionally, Docker images could be split into two (PR image and Release image), or three (one for each .NET SDK with specific workflows or Cake targets).
• CircleCI's native features for building .NET software. Our existing Docker build process is resource-intensive and time-consuming. Transitioning to CircleCI's native jobs/orbs could be a significant improvement.

The 2nd part is slated for delivery in the next release. The current objective of #2034 has been met, and there is no time for further in-depth improvements. Delivery is anticipated for May/June '24, in the subsequent release.

Proposed Changes

• Resolved the outdated 90-second acceptance test Should_timeout_per_default_after_90_seconds introduced in #1834. Refer to https://github.com/ThreeMammals/Ocelot/pull/2045/commits/ae085c40e9429378a563cecedb3489d90837ea1f
• The primary beneficial proposal is the SDK filtering using the dotnet test --framework net8.0 command for PR workflows, enabling builds with the .NET 8 SDK only for pull requests (including all commits for feature & develop branches). Refer to https://github.com/ThreeMammals/Ocelot/pull/2045/commits/c8bbbd224f392f89d5e70e228874f7af6c25c068, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/bb244eb2ac6d030486234eb4c6ccbfbc26199ea6
• Conducted a review, testing, and update of all NuGet packages in the build.cake script. Refer to https://github.com/ThreeMammals/Ocelot/pull/2045/commits/e008bb7cf15a8a70ce99d680546d4051e297031f, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/db3de59099fe52e92679f6d34383f47fcf27302f, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/ae3f238732611c8c80755198300a8bc86abdff8d, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/8bc9907661b9273b091ba0f9bcde303be9b1c3b6.
• In the course of the package review, I prepared a new PR https://github.com/cake-contrib/Cake.Coveralls/pull/124 to address the issue reported in https://github.com/cake-contrib/Cake.Coveralls/issues/123, aiming to upgrade the Cake.Coveralls package. I'm optimistic about finding the repository Maintainer or team lead. :grin:
• Opted to remove Samples projects from Ocelot.sln and instead created a new Ocelot.Release.sln (which includes all projects) and Ocelot.Samples.sln (which contains only sample projects). This modification shaved off 1-5 seconds, although the exact duration change is subtle. It appears to be beneficial. Refer to https://github.com/ThreeMammals/Ocelot/pull/2045/commits/8dab1c0ec44194bf9f229d851b384f17e0bca8c5, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/6ecc11f38111686b1f2fbd03553ee402189cda87, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/32da44f5a27b66e7149d0981055de976eea1cc34, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/524b7530a7c4549f81f12aac839a0c1b87032243, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/6983f2a6a54b83da18d88ed90a16316594658a93, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/e7c02b92ba8138bc94f38a952c6bf3342878e360, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/bdb2847edc876900809061b3683ab9620c7d18fb, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/5592ad988e8e58662dfc677527c188106ce56a32, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/8ccfecdefbe942235f7af3795956480fbed8667b, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/d0d2eec9d0dd375ea5e9c98b473cd1653309617f, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/0f382e0994fe70b6291313c79ce81539f160add6
• Reviewed and updated .circleci/config.yml. Switched off block_workflow job (see https://github.com/ThreeMammals/Ocelot/pull/2045/commits/88dd110a79f56c7e5638705b90aa1d21f8443c0a) and it's strange that this job was ran for PR workflow, I found commit https://github.com/ThreeMammals/Ocelot/commit/fd7c6d7a5b7326af5c09845f176cb498fe4bc3be in git history in which Tom wanted to block multiple concurrent releases a few years ago. So it is not required, and now we have only one workflow running for PR commits, see raman-m/2034 build GitHub checks. So we have only one ci/circleci: build check now. This is a little but awesome improvement.
• Added new resource_class job option with medium+ value for build job. The old default value was medium implicitly for Docker executor. So, this change won extra 3-5 seconds when doing Compile task. But in future it will give more benefits when tests will be parallelized. So, medium+ means 3 vCPU and medium means 2 vCPU. See commit https://github.com/ThreeMammals/Ocelot/pull/2045/commits/f0c38f8f21c244b453b85c7df189bc7fdeced5f0
  • Reviewed StyleCop and standard Code Analyzers settings. Our .editorconfig was outdated due to multiple Visual Studio releases since its addition (see commit 6469e44 on GitHub). Addressed most critical warnings. Refer to commits 94ce8c9 and dd2f27b for disabled C# 12 features, which were incorrectly flagged for C# 11 net7.0 and C# 10 net6.0. The absence of such warnings previously may be attributed to the outdated .editorconfig not aligning with the latest VS version. The Editor Config has been updated, activating and resolving these warnings.
  • Disabled CS0618 warning for testing projects, as warnings about Obsolete definitions are unnecessary there. However, for the src folder projects, this warning will remain until code refactoring is completed. See commit fa29b63 and e5b5c5f for details.
  • Removed restore and build step flags from the dotnet test command for the unit testing project, as they were redundant given the Compile task precedes the testing one. This modification saved approximately 10 seconds (see commit fa7e1ec).
  • Addressed the issue of lengthy console logs on CircleCI during unit testing with the BDDfy framework, which produced logs of 10-15 thousand lines. By forcibly disabling BDDfy console reports, log length was reduced by about 5 thousand lines. See https://github.com/ThreeMammals/Ocelot/pull/2045/commits/a03e74a32b1e80bb512bffadaf42df19f1d294f3, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/ba7d50f560706e67026263525d9ecb98a2237949, https://github.com/ThreeMammals/Ocelot/pull/2045/commits/a01fe6b606436f1b98ef386bfb95b3a4f9aff922 with key changes in UnitTest class.

[raman-m]

TODO

2nd Part

The 2nd part will address aspects of:

• Test parallelism. Currently, only unit tests run in parallel.
• Workflow parallelism. This could shave off a few seconds.
• A review of the unit tests' "waiting" logic: thread blocks, wait times, timeout durations, etc. This is optional but could save some seconds.
• Docker architecture and images. We currently use a heavy Docker image with 3 pre-installed SDKs, which takes 15-20 seconds to download from Docker Hub. Enabling caching could save 10-15 seconds. Additionally, Docker images could be split into two (PR image and Release image), or three (one for each .NET SDK with specific workflows or Cake targets).
• CircleCI's native features for building .NET software. Our existing Docker build process is resource-intensive and time-consuming. Transitioning to CircleCI's native jobs/orbs could be a significant improvement.

The 2nd part is slated for delivery in the next release. The current objective of #2034 has been met, and there is no time for further in-depth improvements. Delivery is anticipated for May/June '24, in the subsequent release.