Implements the mono repo logic required to switch to registering projects using the website.
Architecture
The high-level architecture for project management now looks like this:
All projects are registered by calling the createProject function. All of the configuration option validation we previously did in the mono repo is now done in this function. See the corresponding website PR for more information.
It's worth noting that there is no reason why we could not provide a method for registering projects that uses the CLI. It would simply be a small wrapper on top of the createProject function. The vast majority of the logic would be shared with the UI registration process. I haven't done that in this PR, but I've created a ticket for it.
The propose API endpoint now only requires a project name and safe address. If no project with that name and Gnosis Safe address combination is found in the DB, then an error is thrown.
All the Gnosis Safe configuration information is now stored in the sphinx.lock file which we recommend committing to version control.
When the propose command is run, we always update the sphinx.lock file by querying the website backend.
When the deploy command is run, we rely on the current version of the sphinx.lock file. A project can exist on the website and not in the local sphinx.lock file. In this case, we error recommending the user run npx sphinx sync to fetch the latest lock file.
When the user runs tests that use the sphinx modifier, we rely on the current version of the sphinx.lock file. Like the deploy command, it's possible for the project to exist on the website and not in the local sphinx.lock file and we also error in this case recommending the user run npx sphinx sync.
Backward Compatability
This change is designed to be backward compatible on the website. The user will just no longer be able to register new projects via the propose API endpoint. So if a user continues to use the current version of our plugin, and uses a set of configuration options in their script that correctly match a project that is already registered on the website (correct project name, and Gnosis Safe options that resolve to the correct address), then they will be able to continue proposing to the website without issue. Being backward compatible in this way, will ensure that the release process for this change is as smooth as possible.
However, the changes in the mono repo are breaking changes because the user will need to update their script configuration options. See the migration guide for more information on that.
Testing
You should be able to test this entire change out by running the website locally. You'll just need to checkout this branch, and the corresponding branch in the website repo. You'll of course want to make sure that you have the mono repo packages linked in the website repo.
Once you have that all setup, you should be able to create a project using the UI and then propose using that project name from whatever script you want as long as you have it configured properly. See the migration guide included in this PR for more information on that.
Purpose
Implements the mono repo logic required to switch to registering projects using the website.
Architecture
The high-level architecture for project management now looks like this:
createProject
function. All of the configuration option validation we previously did in the mono repo is now done in this function. See the corresponding website PR for more information.createProject
function. The vast majority of the logic would be shared with the UI registration process. I haven't done that in this PR, but I've created a ticket for it.sphinx.lock
file which we recommend committing to version control.propose
command is run, we always update thesphinx.lock
file by querying the website backend.deploy
command is run, we rely on the current version of thesphinx.lock
file. A project can exist on the website and not in the localsphinx.lock
file. In this case, we error recommending the user runnpx sphinx sync
to fetch the latest lock file.sphinx
modifier, we rely on the current version of thesphinx.lock
file. Like thedeploy
command, it's possible for the project to exist on the website and not in the localsphinx.lock
file and we also error in this case recommending the user runnpx sphinx sync
.Backward Compatability
This change is designed to be backward compatible on the website. The user will just no longer be able to register new projects via the propose API endpoint. So if a user continues to use the current version of our plugin, and uses a set of configuration options in their script that correctly match a project that is already registered on the website (correct project name, and Gnosis Safe options that resolve to the correct address), then they will be able to continue proposing to the website without issue. Being backward compatible in this way, will ensure that the release process for this change is as smooth as possible.
However, the changes in the mono repo are breaking changes because the user will need to update their script configuration options. See the migration guide for more information on that.
Testing
You should be able to test this entire change out by running the website locally. You'll just need to checkout this branch, and the corresponding branch in the website repo. You'll of course want to make sure that you have the mono repo packages linked in the website repo.
Once you have that all setup, you should be able to create a project using the UI and then propose using that project name from whatever script you want as long as you have it configured properly. See the migration guide included in this PR for more information on that.
Todo