update person page generation workflow to adopt TRR workflow #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "contributors"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As a start toward #4, I have made a first pass at updating the person page generation workflow to be in line with that that @msz and @mih developed for the TRR379 website. Testing locally it doesn't seem to break, but I haven't curated any updated person records to really see if it works much differently than the old workflow in what it generates. At the very least, it should fix the
dtc read-pagesissue that has been making the current workflows fail :)update person page generation workflow to adopt TRR workflowto WIP: update person page generation workflow to adopt TRR workflow@ -15,0 +30,4 @@get_file_content: falsepath: code- name: Download extra dataThe data in this step isn't actually used in other places in this workflow. On the trr workflow it is used to infer the TRR-related affiliation of a person (infer-site.py), but we would not need this and are not running it. This step can in my opinion be removed.
@ -33,1 +64,4 @@cd ${{ steps.codecheckout.outputs.path }}uv sync --lockeddtc read-pages https://pool.psychoinformatics.de/api/public/records/p/XYZPerson \| qrg filter-linked-pid --api-url https://pool.psychoinformatics.de/api public xyzrsens:projects/4b434ab4-929e-4d64-97e0-ff334c6a6ff2 associated_with \I believe this used to point to the psychoinformatics Project, but its PID was changed (search for it in https://pool.psychoinformatics.de/ui/?sh%3ANodeShape=xyzri%3AXYZProject). I believe the pid should be
xyzrins:.(yes, just a dot)For completeness, here is the query (without the last line with
persons.py) that I'm running, and its output (jqonly for better readability)output
Thanks - I realized I did actually make this change locally but didn't push it, so will do that with the next round of updates.
@ -33,3 +67,3 @@| qrg filter-linked-pid --api-url https://pool.psychoinformatics.de/api public xyzrsens:projects/4b434ab4-929e-4d64-97e0-ff334c6a6ff2 associated_with \| qrg inline-records --api-url https://pool.psychoinformatics.de/api -c public -p delegated_by -p delegated_by::roles -p identifiers::creator \| qrg render-record page_templates/person.md.j2 'content/{__pid_curie_reference}/_index.md'| uv run person.py - ${{ steps.websitecheckout.outputs.path }}/content/personsAt the moment, running
person.pyfrom https://hub.trr379.de/q02/pool-publication-page/src/branch/main/person.py doesn't do anything (not even overwriting existing person pages). There is a check whether the PID starts with a trr-related prefix, and only if there is, a record is written. The person records in the Psyinf pool usexyzrinsas a prefix.For now, to get the workflow to run again, I believe we should keep the previous
This works out of the box. When I let this run locally, it creates person records under their new name:
This is good and expected, we should remove the old records with non-human-readable pids.
I agree with this analysis. The prefix should become configurable in the TRR tool (likely not the only thing that needs to change).
More broadly speaking, filtering by prefix in TRR is a combination of assumptions and convenience; these assumptions can be challenged:
@ -15,0 +28,4 @@with:repository: https://hub.trr379.de/q02/pool-publication-pageget_file_content: falsepath: codeI realized while testing the workflow that there already is a code directory in this repository, and cloning of
pool-publication-pagefails cloning intocode. But as we are not yet using the scripts from the repository, I will comment out this step.abd2392acc93cff6be97@ -31,3 +57,2 @@run: |read-pages https://pool.psychoinformatics.de/api/public/records/p/XYZPerson \| qrg filter-linked-pid --api-url https://pool.psychoinformatics.de/api public xyzrsens:projects/4b434ab4-929e-4d64-97e0-ff334c6a6ff2 associated_with \uv sync --lockedwhat is the reason for running
uv synced --lockedhere? I see anerror: No `pyproject.toml` found in current directory or any parent directoryI have removed this piece
a6d26c59673ce1ebaa89WIP: update person page generation workflow to adopt TRR workflowto update person page generation workflow to adopt TRR workflowThis PR is LGTM from my point of view. It has already ran once and committed updated person records under their new pid - this is why the PR now also removes person records filed under the old pid.
One thing I noted is that there is no token involved. It is my understanding that all content from the pool is public and a token is thus not needed, but if we ever need to fetch protected data, a token should be added.
@ -16,3 +36,1 @@uses: astral-sh/setup-uv@v6- name: Install qrg suiterun: uv tool install https://hub.psychoinformatics.de/datalink/query-rse-group.git --with-executables-from dump-things-pyclientrun: curl -LsSf https://astral.sh/uv/install.sh | shI think using the install action was fine.
brought it back
The workflow uses a TRR379-related email. This should change. Maybe use the domain that forgejo already knows.
f31d0dc1146825d0078d3084680cb2dff4780754dff478075482ff5dee0182ff5dee01bc6fbc1fb5bc6fbc1fb566a731a7b9