Skip to content
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

Automatic deployment from optimade-python-tools #4

Open
ml-evs opened this issue Nov 25, 2020 · 2 comments
Open

Automatic deployment from optimade-python-tools #4

ml-evs opened this issue Nov 25, 2020 · 2 comments
Labels
enhancement New feature or request suggestion

Comments

@ml-evs
Copy link
Member

ml-evs commented Nov 25, 2020

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.

@ml-evs ml-evs added enhancement New feature or request suggestion labels Nov 25, 2020
@CasperWA
Copy link
Member

CasperWA commented Nov 25, 2020

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
Copy link
Member Author

ml-evs commented Nov 25, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request suggestion
Projects
None yet
Development

No branches or pull requests

2 participants