You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current OpenAPI schema update loop isn't very ergonomic. I would guess that we will stick to the optimade-python-tools schema generated for the foreseeable future, so it's probably worth streamlining it a bit.
My suggestion for this repository is the following:
Set up dependabot to watch the optimade-python-tools package for new releases (or commits to master if we want to be bleeding edge).
In the CI of this repository, copy the schema files from optimade-python-tools and commits any changes to the OpenAPI schemas into this repository (either as PR that can be checked, or directly to a branch). These changes can be put in the appropriately versioned folder according to the reported __optimade_version__ supported by the python tools package.
The main specification repo can then add this repository as a git submodule, which can also be watched by dependabot for changes, pulling the appropriate version into develop/master.
I'm happy to set this up if we think its a good idea.
The text was updated successfully, but these errors were encountered:
Won't dependabot setup a PR of its own?
Perhaps the solution here would be to move the responsibility of creating PRs (updating the schemas) to optimade-python-tools; creating a workflow that runs for all pushes to master, checks the OpenAPI schemas compared to the previous version, check if there are changes, if yes, then open a PR in this repository with the new files.
What do you think?
I understand that the responsibility should really be all in this repository, but I think it makes it too awkward?
That would also work, though don't think its such a big deal that dependabot makes its own PR too. I just suggest dependabot as the simplest way to track version changes from this repository.
We should decouple this either way, by doing the steps in the reverse order. I think 3. is the most fiddly bit, and it depends on what we decide about maintaining two specification versions. A push to this repo could either lead to a PR needing to be made vs develop or master in the spec repo, depending on the version label of the folder that changed... again something custom (i.e. this repo pushing changes) might be better than dependabot here.
Our current OpenAPI schema update loop isn't very ergonomic. I would guess that we will stick to the optimade-python-tools schema generated for the foreseeable future, so it's probably worth streamlining it a bit.
My suggestion for this repository is the following:
__optimade_version__
supported by the python tools package.I'm happy to set this up if we think its a good idea.
The text was updated successfully, but these errors were encountered: