q04/www.trr379.de

Fork 2

Add all components allowing person depiction registration workflow #27

Merged

mih merged 2 commits from depiction-workflow into main

2026-03-31 10:52:55 +00:00

jsheunis commented

2026-03-30 08:47:08 +00:00

Member

The register-person-depictions workflow needs to run regularly (and be triggerrable) such that any depictions uploaded via the pool can become part of this repository in order to be rendered on the website.

The actions are added to support the workflow, and models the setup at https://hub.psychoinformatics.de/www/www-from-model/src/branch/main.

Regarding the implication of overwriting existing portraits; currently the git annex addurl command will fail when adding a url for a distribution that has a different checksum than the existing one, which is expected. But this won't make the workflow fail (by design). The implication is that new portrait uploads will not take precedence. We should decide on a convention for this use case, for example:

new uploads always take precedence (in which case we need to add a git rm step to the workflow code), or
uploads marked with a specific annotation tag take precedence (which would need the python script to be updated)

To be taken into account with the above is the way in which the hugo template decides which portrait to render. In the Psyinf www-from-model scenario the hugo template takes the first match of a portrait.* wildcard: see the code. This means: priority could be decided by the upload registration script, but this priority should be marked for the hugo template step as well.

The `register-person-depictions` workflow needs to run regularly (and be triggerrable) such that any depictions uploaded via the pool can become part of this repository in order to be rendered on the website. The actions are added to support the workflow, and models the setup at https://hub.psychoinformatics.de/www/www-from-model/src/branch/main. Regarding the implication of overwriting existing portraits; currently the `git annex addurl` command will fail when adding a url for a distribution that has a different checksum than the existing one, which is expected. But this won't make the workflow fail (by design). The implication is that new portrait uploads will not take precedence. We should decide on a convention for this use case, for example: - new uploads always take precedence (in which case we need to add a `git rm` step to the workflow code), or - uploads marked with a specific annotation tag take precedence (which would need the python script to be updated) To be taken into account with the above is the way in which the hugo template decides which portrait to render. In the Psyinf `www-from-model` scenario the hugo template takes the first match of a `portrait.*` wildcard: see [the code](https://hub.psychoinformatics.de/www/www-from-model/src/commit/867c198116e5e83b35c529d51f603ef35ab63b62/layouts/_default/person.html#L14-L24). This means: priority could be decided by the upload registration script, but this priority should be marked for the hugo template step as well.

jsheunis added 1 commit

2026-03-30 08:47:08 +00:00

Add all components allowing person depiction registration workflow e55ffc96a1

TODO: decide whether script at code/get_person_depiction_urls.py should support
a 'kind' parameter, which means it can be generalized and can live at a level
higher than this repository.

jsheunis changed title from ~~Add all components allowing person depiction registration workflow~~ to WIP: Add all components allowing person depiction registration workflow

2026-03-30 14:05:39 +00:00

jsheunis added 1 commit

2026-03-31 10:17:48 +00:00

Use generalized person-depiction-distribution-url script from orinoco/knowledge-enrichment repo

Deploy on webserver / Build site and deploy on success (push) Successful in 3m42s

Details

d483b4c10c

jsheunis changed title from ~~WIP: Add all components allowing person depiction registration workflow~~ to Add all components allowing person depiction registration workflow

2026-03-31 10:26:07 +00:00

a.wagner commented

2026-03-31 10:42:11 +00:00

First-time contributor

new uploads always take precedence (in which case we need to add a git rm step to the workflow code), or

This feels like it would be simpler UX for a user, because they wouldn't need to remember adding a tag. If an rm is undesirable, though, maybe there could be a way to have the editor automatically attach a tag in the background?

Out of curiosity, if the tag-based approach is adopted, what would happen if I upload my picture (first time), then update (with a tag), and then update a second time (same tag?)?

> new uploads always take precedence (in which case we need to add a git rm step to the workflow code), or This feels like it would be simpler UX for a user, because they wouldn't need to remember adding a tag. If an ``rm`` is undesirable, though, maybe there could be a way to have the editor automatically attach a tag in the background? Out of curiosity, if the tag-based approach is adopted, what would happen if I upload my picture (first time), then update (with a tag), and then update a second time (same tag?)?

mih commented

2026-03-31 10:52:45 +00:00

Owner

I think a new upload should take precedence. In general, I think that is needs some form of signaling which particular item to take, whenever there is more than one.

I will merge this now. Changes can be made later.

Thanks!

I think a new upload should take precedence. In general, I think that is needs some form of signaling which particular item to take, whenever there is more than one. I will merge this now. Changes can be made later. Thanks!

mih merged commit d483b4c10c into main

2026-03-31 10:52:55 +00:00

mih deleted branch depiction-workflow

2026-03-31 10:52:55 +00:00

No reviewers

No labels

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

q04/www.trr379.de!27

No description provided.

Rows
Columns