Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expectedSupplyAssets behaving differenly locally and in CI-CD pipeline (gitlab) #93

Open
codekoriko opened this issue Mar 26, 2024 · 2 comments

Comments

@codekoriko
Copy link

codekoriko commented Mar 26, 2024

I'm using hardhat to fork the mainnet and run unittest for my api calls and I got an issue when testing the function

export async function getLoanTokenSupplied(
  publicClient: PublicClient,
  marketParam: MorphoMarketParams,
  userAddress: EOAAddress,
): Promise<bigint> {
  return await publicClient.readContract({
    address: leverosAddress,
    abi: LeverosMorphoBlueAbi,
    functionName: 'supplyAssetsUser',
    args: [ marketParam, userAddress]
  })
}

my test as follow

  it('retrieves the amount of loanToken a given user has supplied', async function () {
    await loadFixture(deployLeveros);
    const { userWallet } = await loadFixture(setUpLeveros);
    const publicClient = await hre.viem.getPublicClient();

    const amountSuppliedByUser = await getLoanTokenSupplied(
      publicClient,
      getMorphoMarketParam(leverosParam),
      userWallet.account!.address as EOAAddress,
    )
    expect(amountSuppliedByUser).to.approximately(AMOUNT_LOAN_TOKEN_SUPPLIED, BigInt(147498892026))
  });

The test passes when I run it locally npx hardhat test but the same test fails consistently when running in my CI-CD pipeline on Gitlab, with an assertion error:

AssertionError: expected 10000000147498892026 to equal 10000000000000000000

the morpho function supplyAssetsUser used in that test says in its docstring says:

Returns the expected supply assets balance of user on a market after having accrued interest

Would that consistent 147498892026 discrepancy comes from that accrues interest calculation which somehow behave differently locally and in my CI-CD docker environement?

here is my .gitlab-ci.yml content

include:
  - template: Security/SAST.gitlab-ci.yml


default:
  tags:
    - local_runner
  before_script:
    - corepack enable
    - corepack prepare pnpm@latest-8 --activate
    - pnpm config set store-dir .pnpm-store

stages:
  - build_container
  - lint
  - install_project
  - test
  - security

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  CI_REGISTRY: registry.gitlab.com
  TEST_IMAGE: $CI_REGISTRY/leveros1/leveros-v1-core/node20-forge:latest
  ETH_RPC_URL: "https://cloudflare-eth.com"

sast:
  before_script: []
  # You can override the included template(s) by including variable overrides
  # SAST customization: https://docs.gitlab.com/ee/user/application_security/sast/#customizing-the-sast-settings
  # Secret Detection customization: https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings
  # Dependency Scanning customization: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-the-dependency-scanning-settings
  # Container Scanning customization: https://docs.gitlab.com/ee/user/application_security/container_scanning/#customizing-the-container-scanning-settings
  # Note that environment variables can be set in several places
  # See https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence
  stage: security

build_and_push:
  when:
    manual
  before_script: []
  image: docker:latest
  services:
    - docker:dind
  stage: build_container
  script:
    - echo "Building Docker image..."
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $TEST_IMAGE -f test/Dockerfile .
    - docker push $TEST_IMAGE

lint-solhint:
  stage: lint
  image: $TEST_IMAGE
  script:
    - pnpm install
    - pnpm run lint

.install:
  script:
    - forge --version
    - pnpm i
    - rm -rf lib/*
    - forge install foundry-rs/forge-std --no-commit
    - forge install morpho-org/morpho-blue --no-commit
    - forge install morpho-org/morpho-blue-oracles --no-commit
    - forge update morpho-org/morpho-blue-oracles # no idea why it doesn't fetch that latest version. updated today by morpho, some CDN caching?
    # cmd 'forge install OpenZeppelin/[email protected] --no-commit' works in local but not in CI. workaround: manually checkout the version in the submodule
    # downgrade morpho-blue-oracles's openzeppelin to accommodate Morpho pinned to solc 0.8.19. temporary? workaround for issue: https://github.com/morpho-org/morpho-blue/issues/672#issuecomment-1978740721
    - (cd lib/morpho-blue-oracles/lib/openzeppelin-contracts && git fetch --tags && git checkout v4.9.6)
    - forge install OpenZeppelin/openzeppelin-contracts --no-commit
    - (cd lib/openzeppelin-contracts && git fetch --tags && git checkout v4.9.6)

test-forge:
  stage: test
  image: $TEST_IMAGE
  script:
    - !reference [.install, script]
    - forge test

test-hardhat:
  stage: test
  image: $TEST_IMAGE
  script:
    - !reference [.install, script]
    - npx hardhat test
@MerlinEgalite
Copy link
Contributor

Hey @codekoriko this issue does not seem related to oracles, am I correct?

@codekoriko
Copy link
Author

indeed @MerlinEgalite in that case no oracles involved in my deployment or setup function. I noticed that sometimes I have this few Gwei increase during local testing. That's when I run the test just after doing hardhat clean which delete the cache of EVM calls. The consequence are the chains of calls of my test take more time to execute (and interesting accruing to occur?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants