-
Notifications
You must be signed in to change notification settings - Fork 372
chore: automate SRC version bump #8401
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):
-
Update
unreleased_changelog.md(if there are behavior changes, even if they are
non-breaking). -
Are there BREAKING changes?
-
Is a data migration needed?
-
Security review?
How to Satisfy This Automatic Review
-
Go to the bottom of the pull request page.
-
Look for where it says this bot is requesting changes.
-
Click the three dots to the right.
-
Select "Dismiss review".
-
In the text entry box, respond to each of the numbered items in the previous
section, declare one of the following:
-
Done.
-
$REASON_WHY_NO_NEED. E.g. for
unreleased_changelog.md, "No
canister behavior changes.", or for item 2, "Existing APIs
behave as before.".
Brief Guide to "Externally Visible" Changes
"Externally visible behavior change" is very often due to some NEW canister API.
Changes to EXISTING APIs are more likely to be "breaking".
If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.
If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.
Reference(s)
For a more comprehensive checklist, see here.
GOVERNANCE_CHECKLIST_REMINDER_DEDUP
No canister behavior changes.
| ], | ||
| runtime_deps = NNS_CANISTER_RUNTIME_DEPS | UNIVERSAL_CANISTER_RUNTIME_DEPS | { | ||
| "SUBNET_RENTAL_CANISTER_WASM_PATH": "@subnet_rental_canister//file", | ||
| "SUBNET_RENTAL_CANISTER_WASM_PATH": "@mainnet_canisters//:subnet_rental.wasm.gz", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the reason that rent_subnet_test uses SRC 0.3.0 was so that we would have evidence that SRC WOULD work before deploying it. Therefore, I don't think this is exactly what we want. I mean, yes, it's good to be able to test against the version of SRC in production, but we also want to run the against the NEXT version of SRC. As a proxy for what's next, I'd want to use the latest code in the master branch of the subnet-rental-canister repo, similar to how here, we use whatever is currently checked out (even uncommitted changes). Well, using the latest master of SRC is not so easy, because it's a separate repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every system test comes in two flavors: mainnet NNS canisters (their version should be as in this PR) and head NNS canisters (their version should be the latest development version - what you want for testing). So let's just clarify how to provide a specific version for the head NNS version of the system tests. In integration tests, you can specify the dependency directly.
This PR adds the subnet rental canister to be tracked as a mainnet canister so that its version used in tests matches the version actually deployed in production.