-
Notifications
You must be signed in to change notification settings - Fork 677
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
feat(v1
): Migration guide
#922
base: master
Are you sure you want to change the base?
Conversation
Deploying with Cloudflare Pages
|
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.
a small self-review
note that i haven't done a grammar check on this yet. will do so tomorrow
v1
): Migration guidev1
): Migration guide
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.
Didn't finish reviewing yet but here's the first batch of comments. Really great overall so far though, will finish giving this a read tomorrow
|
||
### Upgrading your CI | ||
|
||
When it comes to CI, you can add a `version` input field with `v1.0.0` or your desired stable release. This will pin the CI to that stable version. |
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.
does this support ways to specify a range of versions, e.g. v1
to always use the latest v1.x.y
release? we definitely should support something like that, which is common for github actions
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.
Ah, not really—but we could add this and release a new CI toolchain version.
Co-authored-by: Matt Solomon <[email protected]>
35931e8
to
b2bbe4f
Compare
- Snapshot failures between fuzz runs [are now persisted](https://github.com/foundry-rs/foundry/pull/4974), so workarounds are not needed anymore when testing fuzz runs that use snapshots. | ||
- Sensitive broadcast logs are now logged into the `.gitignore`d `cache` directory, instead of being included in the broadcast files that are intended to be committed. | ||
- The base fee calculation on Anvil is now entirely skipped if the fee is set to 0. | ||
- `vm.startPrank` now overwrites the existing prank instead of just erroring. However, the already set prank must be used first. |
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.
However, the already set prank must be used first.
this sentence wasn't immediately clear to me, what does this mean?
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.
Hmm, I believe this might be an undocumented, somewhat recent change on startPrank—when this overwrite change was made, i believe the rule is now that if the prank has not been used, it will error. if it has been used, it will overwrite the existing prank.
so essentially before overwriting the prank you need to use it first
curl -L https://foundry.paradigm.xyz | bash | ||
``` | ||
|
||
This will reinstall `foundryup`. You can then run `foundryup` on your terminal to download the latest `V1` version. |
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.
We should standardize V1
, V1 and v1. I'm indifferent as to which but should be the same across the docs.
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.
Agreed. My pick is v1—but wdyt @gakonst ? needs to align with blog post.
please reconsider the changes to or provide some functionality that allows me to specify the depth, if the intent is to be more strict i'm happy to be more explicit |
This PR contains the migration guide for V1. It contains:
I expect to flesh out more content on this over the next few days to make it more thorough, but I believe this draft covers enough for us to start discussing.
cc @mds1 for feedback!