-
Notifications
You must be signed in to change notification settings - Fork 3
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
Ship released schemas with hubUtils #194
base: main
Are you sure you want to change the base?
Conversation
This will fall back to github if versions are not found.
sorry I haven't got round to this! It's been on my to do list and promise to have a look on Monday. I have a suggestion on how this might work but probably won't get time to get to it today. |
No worries! It's not an urgent thing and it would definitely benefit from careful review. That being said, I will likely be working on the dashboard project next week, so a quick turnaround is not necessary. |
Before doing a detailed review, I wanted to run some higher level thoughts passed you. This is a great improvement but I think we could push the utility even further. One of the biggest difficulties throughout hubverse packages is developing against an under development schema. This would still require internet access to access schema from a branch during development and testing (hence we'd still need to add skips for not online in tests and use set tests against dev branches) and a lot of post release cleanup of tests after a schema release. Given the GitHub version of packages is considered development, I propose we also allow the next under development schema version to be able to be included in To enable this I would like to modify the script to download the schema and turn it into a function that can take a branch argument as an input. For traceability, I also think inclusion of an additional file (yml?) in the
Down the line we could perhaps use such info and webhooks to automatically open PRs to update the latest version? Not needed to start off with though but good documentation for developers will be required instead. Whatever we decide I feel we should add a section in the |
parsing YAML either requires us to write our own janky reader/writer or take on an extra dependency. We already parse JSON, so it's better to use this mechanism.
I think this is a good idea. I did not turn it into a function, however because doing so would require us to put "usethis" as one of the Suggested packages. Since this is code that is only meant for the developers to synchronize data, I kept it in I have implemented the additional file that records the branch, sha, and timestamp as a JSON file because we already have the tools to parse and write JSON. The ability to store the in-development version in this package also means that the |
This PR enables offline schema validation by shipping the schemas directly with hubUtils.
data-raw/schemas.R
. Schemas will live ininst/schemas/
and there is a configuration file calledinst/schemas/update.json
that records the source of the installed version of the schemas (see next section).get_schema_valid_versions()
andget_schema()
that will check if the requested branch is "main" and then return the locally shipped schemas if it is, otherwise they will fall back to checking from GitHubget_schema()
(e.g. they attempt to validate with a newer hub), the relevant schema will be downloaded from GitHub.This will fix #193
New Development Process
As I mentioned in point 1,
data-raw/schemas.R
will synchronize the schemas in this repo with the schemas repo. Based on #194 (comment), I've updated the development process so that we will no longer have to go through something like hubverse-org/hubAdmin#71.Details are found in the CONTRIBUTING document, but in short, the steps for developing against a new schema version are:
One time step (ever)
Add the script as a git pre-push hook:
With the git push hook installed, it will run every time you push to keep your schemas are up-to-date with the branch defined in
inst/schemas/update.json
.This will live locally for this git repository and you can remove it if you do not like it by using
unlink(devtools::proj_path(".git/hooks/pre-push"))
Once per new schema version
When you start work on a new dev version of the schema, you set the default branch. You can do this by either modifying
inst/schemas/update.json
OR you can use theHUBUTILS_DEV_BRANCH
environment variable (which will update that file for you). Once the branch is set ininst/schemas/update.json
, the script will always check for updates on that branch.After new schema release
After the new schema is released, before you can release this package, you must ensure the default branch is set back to "main", which is done in the same way you would set the
development branch.
Actual changes
Note that the 16k changes are mostly due to the schemas. Here's the actual list of content changes: