-
Notifications
You must be signed in to change notification settings - Fork 30
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
chore: run medusa in CI #86
base: main
Are you sure you want to change the base?
Conversation
78e64c5
to
3f7335d
Compare
3f7335d
to
92dd632
Compare
92dd632
to
f753b6b
Compare
04d1cb1
to
204ccc5
Compare
update: I went for the 'run the entire CI inside a container' option, which proved simple enough if we maintain a fork of the docker image, see 0xteddybear/eth-security-toolbox-ci#1 TODO
|
825b36e
to
65562a7
Compare
3f49064
to
54c0819
Compare
63faf10
to
4dc57f9
Compare
4dc57f9
to
7d03a6e
Compare
@@ -63,6 +63,22 @@ jobs: | |||
|
|||
- name: Run tests | |||
run: yarn test:integration | |||
medusa-tests: |
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.
The tiniest nit: separate the actions with a blank line
medusa-tests: | |
medusa-tests: |
0065d63
to
06f3f28
Compare
note: will update ci image version on monday, after the nightly tagged release |
merge after #87
this PR aims to include a short medusa run in CI, to avoid pushing false positives/errors that can be caught within 5min of fuzzing
it's a WIP, and I'm currently torn between 3 approaches:I believe having a docker image all our CI runs in is the way to go, see update belowdocker-based action
this is a derivative of
crytic/echidna-action
, but modified to useeth-security-toolbox
which has mostly up-to-date versions of a typical solidity toolchain, including medusa. with this, we don't have to worry about installing/updating medusa or crytic-compile, but have to (inside the action definition) deal with the mismatch between the github runner assuming everything will be executed as root and the image configuring everything for a normal user namedethsec
pros:
cons:
forge fmt
param, so I had to add afoundryup
in the Dockerfile )running the entire CI inside
eth-security-toolbox
The entire CI workflow would run inside a container that already has most tools in it, so we could do away with most 'setup' steps in workflow definitions.
However, due to the root-vs-nonroot issue outlined above, we would have to either modify most ci steps so they walk around that or maintain a fork/extension of the aforementioned image so it makes everything available to root
pros
cons
create an action to install medusa in the non-containerized gh runner environment
this would be similar to how we install foundry in CI: https://github.com/foundry-rs/foundry-toolchain/
pros:
cons