cerc-io/solidity
16
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

externalTests/README: Recommend using upstream repository directly when possible

Browse Source
This commit is contained in:
Kamil Śliwak 2021-10-25 13:10:15 +02:00
parent b8aed7ca86
commit 14210825b1
1 changed files with 13 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
test/externalTests/README.md
View File

@ -13,16 +13,17 @@ these projects *can* be upgraded at all.
### Recommended workflow ### Recommended workflow
#### Adding a new external project #### Adding a new external project
1. Create a fork of the upstream repository in https://github.com/solidity-external-tests/. If the 1. If the upstream code cannot be compiled without modifications, create a fork of the repository
project consists of several repositories, fork them all. in https://github.com/solidity-external-tests/.
2. Remove all the branches except for main one (`master`, `develop`, `main`, etc). This branch is 2. In our fork, remove all the branches except for main one (`master`, `develop`, `main`, etc).
going to be always kept up to date with the upstream repository and should not contain any extra This branch is going to be always kept up to date with the upstream repository and should not
commits. contain any extra commits.
- If the project is not up to date with the latest compiler version but has a branch that is, - If the project is not up to date with the latest compiler version but has a branch that is,
try to use that branch instead. try to use that branch instead.
3. Create a new branch named after the main branch and the compiler version from our `develop` 3. In our fork, create a new branch named after the main branch and the compiler version from our
branch. E.g. if the latest Solidity version is 0.7.5 and the main branch of the external project `develop` branch.
is called `master`, create `master_070`. This is where we will be adding our own commits. E.g. if the latest Solidity version is 0.7.5 and the main branch of the external project
is called `master`, create `master_070`. This is where we will be adding our own commits.
4. Create a script for compiling/testing the project and put it in `test/externalTests/` in the 4. Create a script for compiling/testing the project and put it in `test/externalTests/` in the
Solidity repository. Solidity repository.
- The script should apply workarounds necessary to make the project actually use the compiler - The script should apply workarounds necessary to make the project actually use the compiler
@ -39,12 +40,12 @@ these projects *can* be upgraded at all.
and add necessary workarounds there. Continuing the example above, the new branch would be and add necessary workarounds there. Continuing the example above, the new branch would be
called `master_080` and should be rebased on top of `master_070`. called `master_080` and should be rebased on top of `master_070`.
- The fewer commits in these branches, the better. Ideally, any changes needed to make the compiler - The fewer commits in these branches, the better. Ideally, any changes needed to make the compiler
work should be submitted upstream and our branches should just be tracking the main upstream work should be submitted upstream and our scripts should be using the upstream repository
branch without any extra commits. directly.
#### Updating external projects for a PR that introduces breaking changes in the compiler #### Updating external projects for a PR that introduces breaking changes in the compiler
If a PR to our `breaking` branch introduces changes that will make an external project no longer If a PR to our `breaking` branch introduces changes that will make an external project no longer
compile or pass its tests, the fork needs to be modified: compile or pass its tests, the fork needs to be modified (or created if it does not yet exist):
- If a branch specific to the compiler version from `breaking` does not exist yet: - If a branch specific to the compiler version from `breaking` does not exist yet:
1. Create the branch. It should be based on the version-specific branch used on `develop`. 1. Create the branch. It should be based on the version-specific branch used on `develop`.
2. Make your PR modify the project script in `test/externalScripts/` to use the new branch. 2. Make your PR modify the project script in `test/externalScripts/` to use the new branch.
@ -84,7 +85,7 @@ to use the updated copies of the branches and can be discarded aferwards without
When a non-backwards-compatible version becomes the most recent release, `breaking` branch When a non-backwards-compatible version becomes the most recent release, `breaking` branch
gets merged into `develop` which automatically results in a switch to the newer version-specific gets merged into `develop` which automatically results in a switch to the newer version-specific
branches if they exist. If no changes on our part were necessary, it is completely fine to keep using branches if they exist. If no changes on our part were necessary, it is completely fine to keep using
e.g. the `master_060` of an external project in in Solidity 0.8.x. e.g. the `master_060` of an external project in Solidity 0.8.x.
Since each project is handled separately, this approach may result in a mix of version-specific branches Since each project is handled separately, this approach may result in a mix of version-specific branches
between different external projects. For example, in one project we could could have `master_050` on between different external projects. For example, in one project we could could have `master_050` on