search

Materials-Consortia / schemas

This repository hosts the permanent URLs to OPTIMADE schemas
MIT License
0 stars 2 forks source link

Automatic deployment from optimade-python-tools #4

Open ml-evs opened 4 years ago

ml-evs commented 4 years ago

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:

  1. Set up dependabot to watch the optimade-python-tools package for new releases (or commits to master if we want to be bleeding edge).
  2. 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.
  3. 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.

CasperWA commented 4 years ago

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?

ml-evs commented 4 years ago

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.