Github action updates for Clarinet

[saralab]

Guide https://www.cloudwithchris.com/blog/automate-adding-gh-issues-projects-beta/

[lgalabru]

Must (2-3 weeks)

• [ ] Re-enable code coverage (@lgalabru)
• [ ] Optimize build time with this simple trick https://hiropbc.slack.com/archives/CEK6NUGHJ/p1664788525588889 (@aravindgee)
• [ ] Create release workflow for components/clarity-vscode - inspired from https://github.com/hirosystems/clarity-lsp (@aravindgee)
• [x] Flow CI broken (PR): expected actions not running
• [x] Remove clarity-repl-linux-x64-glibc.tar.gz

Should (3-6 weeks)

• [ ] Automate releases of components/chainhook-event-observer on crates.io (@aravindgee)
• [x] Re-enable MUSL builds after handling https://github.com/hirosystems/clarinet/issues/560 (@lgalabru)
• [ ] Flow CI broken (Release): clarinet-darwin-arm64.tar.gz is "corrupted" (cc @obycode)
• [ ] Push clarity-repl-js to NPM (https://www.npmjs.com/package/clarity-repl)
• [x] Is clarinet-deno still functional?
• [ ] Push stacks-rpc-client to crate-io

Could

• [x] Automate releases of components/stacks-devnet after handling https://github.com/hirosystems/clarinet/issues/560 (@lgalabru)
• [ ] Update and migrate https://hirosystems.github.io/clarity-repl/ to https://hirosystems.github.io/clarinet/ (@hugocaillard)

Would

• [x] Setup board automation (@aravindgee)
• [x] Automate releases of components/clarity-jupyter on crates.io and docker after handling https://github.com/hirosystems/clarinet/issues/560 (@aravindgee)
• [x] Rename oreo-linux-x64-glibc.tar.gz -> chainhook-event-observer-linux-x64-glibc.tar.gz

[lgalabru]

Related https://github.com/hirosystems/clarinet/issues/491

[aravindgee]

Reviewed the status quo with Ludo, working on "Must" items first.

[aravindgee]

Optimize build time - @lgalabru Clarinet build time is already optimized through the use of a matrix (example).

Current total build time is close to 1hr, is this acceptable? If not, what would be an area for improvement?

[hugoclrd]

Could it be feasible / desirable to only triggers the actions impacted by a change. For example, an update to the clarity-vscode component code has no impact on clarinet or any of the rust code and we don't need to build it

[aravindgee]

@hugocaillard Yes it's feasible! If you're referring to PR #654, I've updated the logic to trigger the build only when the clarity-vscode subdirectory is updated.

[aravindgee]

todo: Optimize build time for clarinet packages - investigate additional paths for improving build time - eg. parallelize by platform (h/t @lgalabru ) and docker image generation.

[aravindgee]

Reviewed build time bottleneck with Ludo - since its not a major concern, we agreed to deprioritize this for the time being.

Additional concerns brought up by Hugo -

CI - We want to build the lsp for both native and wasm version and run unit tests. We want to build the clarity-vscode extension and run e2e tests (I can add more details about that on the relevant issue). Ideally/optionally, we want to do it only when the relevant components are updated. Also, we don’t want to trigger unnecessary build when only the lsp or vscode components are changed (seed up PR jobs). CD - I have doubts regarding our approach regarding the automated release of vscode extension. I think it would be triggered based on the version tag of a branch, but the Clarinet package and the VSCode extensions versions are not in sync so we can’t have the same tags for both

todo: Rebuild only relevant components on every update

[hugoclrd]

Any thoughts regarding the tags and versions difference between Clarinet and the VSCode extension?

[aravindgee]

Working on a new PR to trigger rebuild of VSCode whenever there's a new clarinet release.

[lgalabru]

hey @aravindgee! I just noticed that this issue was marked as blocked, could you please unpack? Something could have been lost in translation. Also, I noticed that the items

Optimize build time

Create release workflow for components/clarity-vscode

were checked from the list. Looking at https://github.com/hirosystems/clarinet/commits/develop/.github/workflows/ci.yaml I don't see any update on the CI/CD pipelines targeting any of these items, what did I miss? :) Thanks!

[aravindgee]

Hi @lgalabru, @hugocaillard - seeing a lot of failures in the Github actions on Clarinet - with this concern, marked it as blocked to flag it to the team. However I'm currently testing everything end to end to address any issues.

IIRC "optimize build time" was descoped because Github actions had a performance bottleneck (we couldn't get it to build any faster). Components workflow was created for vscode amongst others.. but let me check the quality of the actions, consolidate everything into a single update and get back as soon as I can.

[lgalabru]

Per https://github.com/stacks-network/stacks-blockchain/pull/3274

The official build for clarinet-cli (https://github.com/hirosystems/clarinet/releases/download/v1.4.2/clarinet-linux-x64-glibc.tar.gz) does not run on Ubuntu 20.04 LTS (or below) or CentOS 7. You might need to compile it with lower GLIBC version (2.17 in CentOS 7), in order to make it compatible with most linux distributions.

[aravindgee]

Superceded by #1078 .