[DX-4045] Loopinstall Caching

[kalverra]

Running loopinstall takes ~5 minutes in CI, and there's no proper caching for it. This PR adds it in two tiers.

• Tier 1 caches the binaries. Handy when plugins file doesn't change.
• Tier 2 handles the build cache for the binaries, for when plugin versions do change.

[github-actions]

✅ No conflicts with other open PRs targeting develop

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs

[Copilot]

Pull request overview

Risk Rating: MEDIUM — Changes are confined to CI/workflow + composite actions, but they can affect CI correctness and reliability across many runs (cache correctness, module resolution, and tool installation).

This PR aims to reduce CI time spent running loopinstall by introducing a two-tier caching strategy (cached plugin binaries + cached Go build cache), and also standardizes/caches Aptos (and tweaks Solana caching) via composite actions.

Changes:

• Replace make install-plugins steps in CI with a new composite action that restores/saves cached LOOP plugin binaries and (on miss) a scoped Go build cache.
• Replace direct Aptos CLI installation with a composite action that caches the installed binary.
• Adjust Solana setup caching strategy (path/key), and refactor deployment workflow setup steps.

Scrupulous human review recommended for:

• Cache key correctness vs. what is actually installed/built in:
  • .github/actions/setup-solana/action.yml (new version input vs installer script behavior)
  • .github/actions/setup-loop-plugins/action.yml (plugin-file input vs make install-plugins-public behavior)
• Module resolution in .github/workflows/ci-deployments.yml (go mod download directory vs configured deployment/go.* inputs)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
.github/workflows/ci-deployments.yml	Switches to composite actions for Aptos + LOOP plugins; adjusts module download and DB setup invocation.
.github/workflows/ci-core.yml	Switches Aptos + LOOP plugins setup to composite actions for reuse/caching.
.github/actions/setup-solana/action.yml	Updates Solana caching behavior and introduces a version input.
.github/actions/setup-loop-plugins/action.yml	New composite action implementing two-tier caching for LOOP plugin installation.
.github/actions/setup-aptos/action.yml	New composite action to install Aptos CLI with caching.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (3)

.github/actions/setup-loop-plugins/action.yml:44

• The cache key hash computation uses shasum -a 256, which isn't reliably available on Linux runners by default. If shasum is missing, this step will fail and the whole composite action will break. Consider using sha256sum when available (and optionally falling back to shasum for portability).

        MANIFEST_HASH=""
        if [ -n "$FILES" ]; then
          MANIFEST_HASH=$(cat $FILES 2>/dev/null | shasum -a 256 | awk '{print $1}')
        fi

.github/actions/setup-loop-plugins/action.yml:109

• make install-plugins-local uses go install (see GNUmakefile:109), which respects GOBIN. This action currently sets GOBIN/GOCACHE for the remote plugin installs but not for local plugins, so local plugin binaries won't land in the cached bin directory that this action adds to PATH (and won't benefit from the scoped GOCACHE). Setting the same env vars here makes behavior consistent and ensures the binaries are in the expected directory.

    - name: Install local plugins
      if: ${{ inputs.install-local == 'true' }}
      shell: bash
      run: make install-plugins-local

.github/workflows/ci-deployments.yml:161

• This step name says "vendor packages", but go mod download downloads module dependencies into the module cache (it doesn't populate vendor/). Renaming the step avoids confusion when debugging CI.

      - name: Download Go vendor packages
        working-directory: deployment
        run: go mod download

[cl-sonarqube-production]

Quality Gate failed

Failed conditions
E Security Rating on New Code (required ≥ A)
3 New Blocker Issues (required ≤ 0)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE