Handle private repositories dependencies

[rvignolo]

An action would look like:

name: CI

on:
  push:
    branches:
      - mainnet
      - devnet
      - develop
  pull_request:
    branches:
      - mainnet
      - devnet
      - develop

permissions:
  checks: write
  contents: read
  pull-requests: write

jobs:
  contracts:
    name: Contracts
    uses: HatomProtocol/hatom-sc-actions/.github/workflows/contracts.yml@main
    with:
      rust-toolchain: nightly-2023-12-11
    secrets:
      token: ${{ secrets.GITHUB_TOKEN }}
      deploy-keys: |
        ${{ secrets.SC_REPOSITORY_1_SSH_DEPLOY_PRIVATE_KEY }}
        ${{ secrets.SC_REPOSITORY_2_SSH_DEPLOY_PRIVATE_KEY }}

or

name: On release, build contracts

on:
  release:
    types: [published]

permissions:
  contents: write

jobs:
  build:
    uses: HatomProtocol/hatom-sc-actions/.github/workflows/reproducible-build.yml@main
    with:
      image_tag: v6.1.1
      attach_to_existing_release: true
      package_whole_project_src: true
    secrets:
      deploy-keys: |
        ${{ secrets.SC_REPOSITORY_1_SSH_DEPLOY_PRIVATE_KEY }}
        ${{ secrets.SC_REPOSITORY_2_SSH_DEPLOY_PRIVATE_KEY }}

[rvignolo]

any updates @andreibancioiu ? thank you!

[andreibancioiu]

For reviewers: https://doc.rust-lang.org/nightly/cargo/reference/config.html#netgit-fetch-with-cli

[andreibancioiu]

We'd like to avoid using an additional third party step, if possible (and only have it as a last resort).

[andreibancioiu]

Thus, private dependencies are brought locally, before starting the build, correct (sorry if I misunderstood)?

If so, the usual contract verification flow (which relies on the Docker container to perform the whole build) would not be able to cover this case (however, for verified contracts, private dependencies would not be acceptable, anyway).

[andreibancioiu]

For contracts.yml (not for reproducible-build.yml), the solution you've previously provided (without altering contracts.yml) seems sufficient (an additional step in the workflow file of the repository itself):

multiversx/mx-sdk-rust-contract-builder#59 (comment)

Maybe we can promote and document that solution, and have contracts.yml untouched (at least, from the perspective of setting up credentials)?

[andreibancioiu]

We understand the need of a closed-source contract to depend on private dependencies, e.g. for development phase 👍 - of course, this is not wise for contracts deployed on mainnet - such contracts cannot pass the verified and reproducible build check.

Though, how would you feel about the options below?

(A) have your private dependencies brought as git submodules in your main private repository, then alter the Cargo.toml to point to them (of course, making your project open-source would reveal the source code of the dependencies, as well).

(B) in the Docker images for reproducible builds, we can enable ssh-agent, and run ssh-add (if any key is provided in the Docker environment) - I did not yet test this approach, though.

(C) allow reproducible-build.yml to be parametrized with the fully qualified-name of a Docker image (instead of image_tag only) - this way, you can use a custom Docker image to perform the build of a closed-source contract.

[andreibancioiu]

@rvignolo, sorry for the delayed response 🙏