Put GH Action in separate repo

[CasperWA]

GitHub recommends to dedicate a repo for a publicly usable Action, see here.
The main point being splitting versioning.

This makes sense to me, so I suggest to move the Action to another repo.
What should the name be?

• optimade-validator
• optimade-validator-action (most likely this one)
• optimade-action

Edit:
Also, add issue in new repo to add possibility to use specific branch, tag, or even commit from optimade-python-tools.

[ml-evs]

Sounds sensible, as long as the validator code stays in the main repo (and is tied to our grammar).

I think my vote is for optimade-validator-action, in that case.

[ml-evs]

One question does spring to mind, does this mean we won't be able to use the validator action on arbitaray commits inside optimade-python-tools? My validation of odbx is currently using the action version pinned to master, rather than the last release. Perhaps this could be added to the Action is a parameter?

[shyamd]

We can add options where the validator uses one of:

• the most recent version of git
• specific version of optimade-python-tools

Would that be sufficient?

[CasperWA]

One question does spring to mind, does this mean we won't be able to use the validator action on arbitaray commits inside optimade-python-tools? My validation of odbx is currently using the action version pinned to master, rather than the last release. Perhaps this could be added to the Action is a parameter?

I am not completely sure what you mean by this? But taking a guess, I'd think you are pointing to a possible issue of updating the validator in this repo and then the PR tests may fail, since the action is pointing to an older edition of this repo?
Or even that changes introduced in the validator is simply not released yet, but is present in the master branch.
This seems like a reasonable issue, and one that may indeed be remedied by your suggestion.
At the moment it is git cloning this repo and installing as editable, so it shouldn't be a problem if you use master at the moment as you write, but ideally I would not do this in the action, but rather pin to a release of this repo and then maybe have a branch latest that then still git clones and installs as editable, i.e., one could run the validator using @latest instead of @v1 to use the latest develop version of this repo and its validator instead of using the latest released version.
Or it may be a flag in the action, like you suggest.

Indeed, this is echoing what @shyamd is suggesting.

[ml-evs]

I am not completely sure what you mean by this? But taking a guess, I'd think you are pointing to a possible issue of updating the validator in this repo and then the PR tests may fail, since the action is pointing to an older edition of this repo?
Or even that changes introduced in the validator is simply not released yet, but is present in the master branch.

Yes, currently I can test my implementation against the optimade-python-tools commit that was used to create it (say, version 0.5.0), but once the validator action is separate, it will only be able to test whatever version of the models/grammar/validator that the action installs.

We can add options where the validator uses one of:

* the most recent version of git

* specific version of optimade-python-tools

Would that be sufficient?

This suggestion is fine by me in the long-term, and in the short-term while implementations are in a state of flux, they can always just use the validator directly from the python-tools repo.

[shyamd]

I will build a new repo later today for this.

[CasperWA]

I will build a new repo later today for this.

Already on it 😅 (https://github.com/Materials-Consortia/optimade-validator-action)

[CasperWA]

Status update:
The repo is well underway. I have already 3 PR's waiting to be merged. One is blocking, since it relates to fixing the CI tests, another implements the new argument, and the final one simply updates the README.

As soon as they have been released I will release v1 as well as v1.0.0 of the action.
I think the workflow should be something like:
Whenever v1 is updated (minor or patch version) the tag/branch v1 should be updated to the latest v1.x.x so that users referencing Materials-Consortia/optimade-validator-action@v1 always get the latest version 1.x.x. If/when we fundamentally change the action or validator, a v2 can be released.

Also, I will not create a PR removing the action from this repo until v1 is released of the other (and @ml-evs has possibly checked it against his server).