ci: ci: deprecate circle ci in favour of github actions

[galargh]

Important

Before merging this PR

• Set up the following repository configuration variables:
  • DOCKERHUB_USERNAME
• Set up the following repository secrets:
  • DOCKERHUB_TOKEN
  • GORELEASER_KEY
• Update required checks on the protected branches

Important

After merging this PR:

• Disable lotus project in CircleCI
• Propagate all the GitHub Actions PRs to the release branch (?)

Related Issues

#11734

Proposed Changes

This PR removes CircleCI configuration from the repository entirely.

Additional Info

We have analysed the CircleCI vs GitHub Actions fitness in the period 2024-04-08 - 2024-04-15:

• FilOz - Lotus - CircleCI vs GitHub Actions - 2024-04-15 - Comparison (Last 7 Days).pdf

The analysis suggests we are ready to deprecate CircleCI in favour of GitHub Actions.

• The workflow success rate in GitHub Actions is higher (min. 57%) than in CircleCI (min. 36%)
• The median duration of workflows in GitHub Actions is lower (max. 13 minutes) than in CircleCI (max. 16 minutes)
• The maximum duration of workflows in GitHub Actions is higher ⚠️ (max. 37 hours) than in CircleCI (max. 27 minutes) -> We were able to connect the outlier in GitHub Actions with an issue with self-hosted runners infrastructure where a runner might not get scheduled properly. We set up comprehensive monitoring for this issue, and we can quickly manually fix it if it happens again. We are also working on automation for the rescheduling process which should be complete within a month.
• On master, only Test (itest-gateway) job is more flaky in GitHub Actions (75% success rate) than in CircleCI (92.86% success rate); there are 8 other tests that are more flaky in CircleCI than in GitHub Actions
• On all branches, there are fewer tests that are only flaky in GitHub Actions (9) than only in CircleCI (20)

Before proceeding with the deprecation, we should decide whether the tests that we noticed to be flaky/failing only in GitHub Actions should be investigated. Here is a list of the tests (at most 2 failures in 54 runs):

• Test (itest-path_type_filters)
• Test (itest-eth_filter)
• Test (itest-wdpost)
• Test (itest-deals_pricing)
• Test (itest-sector_finalize_early)
• Test (itest-wdpost_worker_config)
• Test (itest-cli)
• Test (multicore-sdr)
• Test (itest-harmonydb)

We should also decide how to proceed with the propagation of deprecation to the release branches. We imagine the course of action to look something like this.

1. Merge the deprecation PR
2. Change the required checks to the ones from GitHub Actions
3. Disable CircleCI
4. Cherry pick the GitHub Actions changes onto the release branch

Does it make sense to the team? Are there any other aspects of the process that we should take into account?

Finally, please note that we haven't tested the GitHub Actions release workflows with publishing credentials yet (to avoid duplicate releases). Because of this, we'd suggest coordinating the next release with us - that way we'd be able to immediately react if something unexpected were to happen.

Cost Breakdown

CircleCI

7 Days Total: $354.47

The above figure assumes a CircleCI credit price of $0.0006.

GitHub Actions

7 Days Total: $176.54

Please note that the figures shown cover both self-hosted runners infrastructure, as well as other DX services such as GitHub monitoring, for example.

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• If the PR affects users (e.g., new feature, bug fix, system requirements change), update the CHANGELOG.md and add details to the UNRELEASED section.
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[rvagg]

Variable and secrets are done.

Status checks are ~done:

master:

release/*:

releases is a bit trickier - it had ci in it, which is the parent of all of the ci/* Circle jobs, but we don't have an equivalent. For now I'm just going with the basic checks rather than all although surely there must be a way to specify all?

[rvagg]

@galargh there is a v1.27.0 release due soon, shall we coordinate on merging this and using it to test releases for that? I think @rjan90 could probably cut another RC just to test this out since we're already up to rc2 and not yet at final. Now might be a good time to make sure GoReleaser and DockerHub publishing works with GHA.

The outstanding items here I believe are to disable Circle integration and merge this PR (once rebased).

The flaky tests thing is a problem, but one we're going to have to chip away at rather than treat as a blocker to this because they are hard.