[release] upgrade Staking, StakingManager to mainnet

[ianhe8x]

Summary by CodeRabbit

• Chores
  • Ensured CI/CD pipelines initialize the package manager before installs to improve build consistency.
  • Updated mainnet contract deployment data for Staking and StakingManager (addresses, checksums, timestamps).
  • Bumped package version from 1.10.0-1 to 1.10.0.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

Added Corepack initialization to multiple GitHub Actions workflows so Corepack runs before Yarn; updated mainnet publish data for Staking and StakingManager (addresses, bytecode hashes, timestamps); bumped package version from 1.10.0-1 to 1.10.0.

Changes

Cohort / File(s)	Summary
GitHub Actions — Corepack init .github/workflows/* — deploy.yml, docs-deploy.yml, fuzz.yml, pr.yml, prerelease.yml, release.yml, upgrade.yml	Inserted corepack enable (as a separate run step or prefixed to the yarn command) after Node setup and before any yarn invocation.
Mainnet publish data publish/mainnet.json	Replaced Staking and StakingManager block entries: updated innerAddress, bytecodeHash, and lastUpdate timestamps to the new values. No other structural changes.
Package metadata package.json	Version changed from 1.10.0-1 to 1.10.0. No other edits.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant GH as GitHub Actions
    participant Node as setup-node (Node 18)
    participant Corepack as corepack
    participant Yarn as yarn

    GH->>Node: setup Node 18
    Note right of Node: existing step
    Node-->>GH: Node ready
    GH->>Corepack: run "corepack enable"
    Corepack-->>GH: Corepack enabled
    GH->>Yarn: run "yarn" (or "corepack enable && yarn")
    Yarn-->>GH: dependencies installed / commands run

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Homogeneous changes across multiple workflow files (same insertion pattern).
• Value-only updates in publish/mainnet.json and a single package version bump—low logic density.
• Pay extra attention to:
  • Correct placement of corepack enable relative to Node setup steps in each workflow.
  • No accidental command concatenation or YAML indentation issues in workflows.
  • Verify publish/mainnet.json address/hash values match intended release artifacts.

Possibly related PRs

• [release] upgrade Staking, StakingManager to mainnet #450 — Similar changes to GitHub Actions workflows adding corepack enable and updates to publish/mainnet.json entries.

Poem

🐰 In a burrow lined with dev delight,
I enabled Corepack through the night.
Workflows hop, Yarn springs to play,
Contracts updated — hip hooray! 🎉

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main changes: enabling Corepack in GitHub Actions workflows across multiple files and updating Staking/StakingManager contract data on mainnet.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e86c278 and adadd26.

📒 Files selected for processing (1)

• package.json (1 hunks)

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/docs-deploy.yml (1)

13-13: Corepack initialization uses inline chaining—functionally equivalent and acceptable.

While this workflow uses inline command chaining (corepack enable && yarn) instead of separate steps like other workflows, both approaches are functionally identical. The inline format is reasonable for this simpler workflow that doesn't have explicit setup-node configuration. For consistency across the repository, consider aligning the format with other workflows (separate - run: corepack enable step), but this is a minor stylistic preference.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 72fed91 and e86c278.

📒 Files selected for processing (8)

• .github/workflows/deploy.yml (1 hunks)
• .github/workflows/docs-deploy.yml (1 hunks)
• .github/workflows/fuzz.yml (1 hunks)
• .github/workflows/pr.yml (1 hunks)
• .github/workflows/prerelease.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)
• .github/workflows/upgrade.yml (1 hunks)
• publish/mainnet.json (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: pr

🔇 Additional comments (7)

publish/mainnet.json (1)

84-87: Verify mainnet contract addresses and bytecode hashes before merging.

The Staking and StakingManager contract data (addresses and bytecode hashes) have been updated for production mainnet deployment. These changes require confirmation to prevent user funds from being directed to incorrect contract instances.

Verify the following:

• New innerAddresses are correct and match deployed contracts on mainnet
• New bytecodeHash values match the actual deployed bytecode
• Contracts at these addresses have been audited/tested appropriately
• Any dependent systems (indexers, frontends, documentation) are aware of the address change

Before merging, please confirm these details and consider adding deployment notes or a migration guide if users need to perform any actions due to the address change.

Also applies to: 90-93

.github/workflows/fuzz.yml (1)

38-39: Corepack initialization looks good.

The corepack enable command is correctly placed after Node.js setup and before yarn invocation, ensuring the appropriate Yarn version (as configured in package.json) is used. This aligns with best practices for modern Node.js tooling.

.github/workflows/upgrade.yml (1)

40-41: Corepack initialization looks good.

The corepack enable command is correctly positioned after Node.js setup and registry configuration, ensuring proper package manager initialization before yarn runs.

.github/workflows/pr.yml (1)

16-17: Corepack initialization looks good.

The corepack enable step is correctly placed after Node.js setup and before yarn, following standard best practices.

.github/workflows/release.yml (1)

34-35: Corepack initialization looks good.

The corepack enable step is correctly placed after Node.js setup and registry URL configuration, before yarn execution.

.github/workflows/deploy.yml (1)

40-41: Corepack initialization looks good.

The corepack enable step is correctly placed after Node.js setup and registry configuration, before yarn execution.

.github/workflows/prerelease.yml (1)

31-32: Corepack initialization looks good.

The corepack enable step is correctly placed after Node.js setup and before yarn execution.