CI/CD for smart contracts in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of a smart contract deployment script

What is the output of this deployment script snippet when deploying a smart contract using Hardhat?

Blockchain / Solidity

const hre = require('hardhat');
async function main() {
  const Contract = await hre.ethers.getContractFactory('MyContract');
  const contract = await Contract.deploy();
  await contract.deployed();
  console.log('Contract deployed to:', contract.address);
}
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

A SyntaxError: Unexpected token

B Error: ContractFactory not found

C Contract deployed to: 0x1234567890abcdef1234567890abcdef12345678

D Contract deployment failed due to gas limit

💡 Hint

The script logs the deployed contract address on success.

The script deploys the contract and logs its address. Option C shows the expected output format.

🔀 Workflow

intermediate

Correct CI/CD pipeline step order for smart contracts

Which option shows the correct order of steps in a CI/CD pipeline for smart contracts?

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Linting should happen before compilation.

Static analysis and linting catch issues early, then compile, test, and deploy.

❓ Troubleshoot

advanced

Troubleshooting deployment failure due to missing private key

A CI job fails deploying a smart contract with this error: "Error: No private key provided". Which option is the most likely cause?

A The environment variable for the deployer's private key is not set in the CI environment.

B The smart contract code has a syntax error.

C The testnet network is down.

D The gas price is set too low.

💡 Hint

Private keys are usually stored as environment variables in CI.

The error indicates the deployer key is missing, likely due to unset environment variables.

✅ Best Practice

advanced

Best practice for managing secrets in smart contract CI/CD

Which option is the best practice for handling private keys and secrets in a smart contract CI/CD pipeline?

A Commit private keys directly into the repository for easy access.

B Store private keys encrypted in the CI tool's secret manager and inject them at runtime.

C Send private keys via email to the deployment server before each run.

D Hardcode private keys in the deployment scripts.

💡 Hint

Secrets should never be stored in code or sent insecurely.

Using the CI secret manager keeps keys safe and accessible only during deployment.

🧠 Conceptual

expert

Impact of immutable smart contracts on CI/CD updates

Given that deployed smart contracts are immutable, what is the best approach to update contract logic in a CI/CD pipeline?

A Use the same contract address and overwrite the bytecode with the new logic.

B Modify the existing contract code on the blockchain directly via the CI pipeline.

C Pause the blockchain network, update the contract, then resume the network.

D Deploy a new version of the contract and update references in the application to point to the new address.

💡 Hint

Smart contracts cannot be changed once deployed.

Because contracts are immutable, updates require deploying new contracts and redirecting usage.

Practice

1. What is the main purpose of using CI/CD pipelines for smart contracts?

easy

A. To manually write smart contract code faster

B. To avoid writing tests for smart contracts

C. To store smart contracts on a local machine only

D. To automate compiling, testing, and deploying smart contracts

Solution

1. Step 1: Understand CI/CD role in smart contracts

   CI/CD pipelines automate repetitive tasks like compiling, testing, and deploying smart contracts to reduce errors and save time.

2. Step 2: Compare options with CI/CD purpose

   Only To automate compiling, testing, and deploying smart contracts describes automation of compile, test, and deploy steps, which is the core of CI/CD.

3. Final Answer:

   To automate compiling, testing, and deploying smart contracts -> Option D

4. Quick Check:

   CI/CD automates smart contract lifecycle steps = B [OK]

Hint: CI/CD means automate build, test, deploy steps [OK]

Common Mistakes:

• Thinking CI/CD is for manual coding
• Confusing storage with deployment
• Skipping testing in CI/CD

2. Which of the following is the correct syntax to trigger a GitHub Actions workflow on every push to the main branch for smart contract CI/CD?

easy

A. on: push:
branches: [main]

B. trigger: push main

C. on_push: main_branch

D. when: push to main

Solution

1. Step 1: Identify correct GitHub Actions event syntax

   The correct syntax uses 'on:' followed by the event type and branches list, like 'on: push:\n branches: [main]'.

2. Step 2: Compare options to GitHub Actions docs

   Only on: push: branches: [main] matches the official YAML syntax for triggering workflows on push to main branch.

3. Final Answer:

   on: push: branches: [main] -> Option A

4. Quick Check:

   GitHub Actions uses 'on: push' with branches list = A [OK]

Hint: GitHub Actions uses 'on:' with event and branches [OK]

Common Mistakes:

• Using incorrect keywords like 'trigger' or 'when'
• Wrong indentation or missing colon
• Confusing event names

3. Given this GitHub Actions step in a smart contract pipeline:

 - name: Compile Contract
   run: solc --bin MyContract.sol -o build/

What will this command do?

medium

A. Run tests on MyContract.sol

B. Deploy MyContract.sol to blockchain network

C. Compile MyContract.sol and output binary files to build/ directory

D. Delete build/ directory

Solution

1. Step 1: Understand solc compile command

   The command 'solc --bin MyContract.sol -o build/' compiles the Solidity file and outputs binary files to the specified build directory.

2. Step 2: Match command purpose to options

   Only Compile MyContract.sol and output binary files to build/ directory correctly describes compiling and outputting binaries, while others describe unrelated actions.

3. Final Answer:

   Compile MyContract.sol and output binary files to build/ directory -> Option C

4. Quick Check:

   solc --bin compiles and outputs binaries = C [OK]

Hint: solc --bin compiles Solidity to binary output [OK]

Common Mistakes:

• Confusing compile with deploy
• Assuming tests run automatically
• Thinking it deletes files

4. You have this GitHub Actions step to deploy a smart contract:

 - name: Deploy Contract
   run: truffle migrate --network mainnet

But the deployment fails with an error about missing network configuration. What is the likely cause?

medium

A. The 'truffle migrate' command is misspelled

B. The 'mainnet' network is not defined in truffle-config.js

C. The GitHub Actions runner lacks internet access

D. The smart contract code has syntax errors

Solution

1. Step 1: Analyze error about missing network configuration

   The error indicates the deployment tool cannot find the 'mainnet' network settings in the configuration file.

2. Step 2: Identify cause of missing network config

   If 'mainnet' is not defined in truffle-config.js, deployment fails. Syntax errors or internet issues cause different errors, and the command spelling is correct.

3. Final Answer:

   The 'mainnet' network is not defined in truffle-config.js -> Option B

4. Quick Check:

   Missing network config causes deployment failure = D [OK]

Hint: Check truffle-config.js for network definitions first [OK]

Common Mistakes:

• Blaming code syntax for network config errors
• Ignoring configuration files
• Assuming internet issues without checking config

5. You want to ensure your smart contract CI/CD pipeline only deploys contracts after all tests pass and on the 'release' branch. Which GitHub Actions workflow snippet correctly enforces this?

hard

A. on:
push:
branches: [release]
jobs:
build:
steps:
- run: npm test
deploy:
needs: build
if: success()
steps:
- run: truffle migrate --network mainnet

B. on:
push:
branches: [main]
jobs:
deploy:
steps:
- run: truffle migrate --network mainnet

C. on:
pull_request:
branches: [release]
jobs:
test:
steps:
- run: npm test
deploy:
steps:
- run: truffle migrate --network mainnet

D. on:
push:
branches: [release]
jobs:
deploy:
steps:
- run: truffle migrate --network mainnet

Solution

1. Step 1: Identify branch trigger and job dependencies

   The pipeline triggers on push to 'release' branch. It runs tests first in 'build' job, then deploys only if tests succeed using 'needs: build' and 'if: success()'.

2. Step 2: Compare options for correct workflow logic

   on: push: branches: [release] jobs: build: steps: - run: npm test deploy: needs: build if: success() steps: - run: truffle migrate --network mainnet correctly sequences test then deploy with condition and branch filter. Others miss test step, branch, or job dependency.

3. Final Answer:

   on: push: branches: [release] jobs: build: steps: - run: npm test deploy: needs: build if: success() steps: - run: truffle migrate --network mainnet -> Option A

4. Quick Check:

   Test before deploy on release branch = A [OK]

Hint: Use job dependencies and branch filters in workflow [OK]

Common Mistakes:

• Deploying without testing first
• Triggering on wrong branch
• Missing job dependencies or conditions