search

gdcc / dataverse-previewers

A collection of Datafile Previewers that can be configured to work with Dataverse
MIT License
5 stars 15 forks source link

Extend Dataverse-Previewers with React applications and a build workflow #35

Closed JR-1991 closed 1 year ago

JR-1991 commented 1 year ago

What this PR does / why we need it:

This PR addresses the need for a more sustainable and reusable solution for hosting React previewers in the dataverse-previewers repository. Currently, React code is manually converted to HTML/JS/CSS and committed from a separate repository. This approach is inefficient and hinders future development of React previewers. Therefore, this PR introduces new directories and a CI workflow to host both the source and built code in a single repository.

How it works:

This PR introduces two new directories. The first directory, react-source, contains the source code for each previewer. Each previewer's source code is accompanied by a previewer-meta.yml file, which provides important information such as the previewer's name, a checksum functionality, build instructions, and relevant files for hosting the previewer.

During the build process, the resulting files are copied to the betatest directory. Users can now direct their curl commands to this directory to add the previewer to their Dataverse instance. While the building process can still be done manually, this PR includes a CI workflow (build_react_previewers.yml and build_react_previewers.py) that automates the process whenever a push event occurs. The CI workflow follows the build instructions provided in the previewer-meta.yml file.

Additionally, based on a request by @qqmyers, the workflow now includes a check to determine if the source code has changed. If the source code remains the same, the workflow will not proceed. Specifically, it compares the checksum of the checkdir and ensures that it evaluates to the same hash value. However, if there is a change, the builder recalculates the checksum and updates the yml file accordingly.

Additional documentation:

Edits

pdurbin commented 1 year ago

We touched on this PR at standup this morning and Jim said he'd take a look. I don't mind testing it. I'd like to understand how to make a change, for example.

JR-1991 commented 1 year ago

@pdurbin sounds great! Thanks for testing 🙂

In order to introduce changes, you can edit the source code found in react-source. For instance, if you'd like to change behaviour of the HDF5-Previewer you can add changes as usual to the given source code and commit these.

Once changes have been introduced the CI workflow detects those via the previously added checksum found in the previewer-meta.yaml and rebuilds plus pushes the resulting app to the corresponding directory in react-previewers. It also updates the checksum to prevent rebuilding anytime a push event occurs.

qqmyers commented 1 year ago

@JR-1991 - Thanks for looking into automation here! A couple questions/comments:

Could you look at CONTRIBUTING.md and adjust your PR to put the final code in previewers/betatest? Once we get the latest set of previewers/PRs in, we'll probably create a previewers/v1.4 folder and copy the betatest content over. Any changes after that v1.4 release would still go into the betatest dir so that v1.4 isn't changing for those who deploy from github.io.

Is the automation consistent with having PRs against the develop branch and not master? We're nominally doing that to be able to separate accepting code from the decision to have it live on github.io.

JR-1991 commented 1 year ago

@qqmyers thanks for the feedback!

I have adjusted the workflow to match the conditions of contributing. Newly built react previewers are now copied to betatest and all assets (js/css) to their corresponding directory. The H5Web example has been adopted to this and is now available at betatest.

Is the automation consistent with having PRs against the develop branch and not master? We're nominally doing that to be able to separate accepting code from the decision to have it live on github.io.

The automation pushes the built previewer to the checked branch, so there should be no problems with the master. The action though should also be pushed to the develop branch, so maybe this PR should address the develop branch instead?

qqmyers commented 1 year ago

Thanks - yeah, a PR against develop make sense.

JR-1991 commented 1 year ago

Changed the target branch to develop 🙌

pdurbin commented 1 year ago

@JR-1991 hi! I took a quick look but I'm having trouble loading the js file. Please see https://dataverse.zulipchat.com/#narrow/stream/376593-geospatial/topic/plot.20arrays.20from.20HDF5/near/368521444 and thanks!