[WIP] adding GA to create a PR to reproschema-py

[djarecka]

I've created a github workflow that pushes to reproschema-py

I was testing it for the current version so I was testing copying reproschema.jsonld, but it should be updated when we decide that pydantic is in releases directory

It can be also used to update CONTEXTFILE_URL

Unfortunately, I realized that my way of checking what is the latest release, by running ls -lt releases/ | grep ^d | head -1 | awk '{print $9}' works locally, but not in GA. If anyone knows how to change it that would be great.

[Remi-Gau]

Quick thoughts:

• maybe we could run this one when we do a github release rather than monitoring the release folder on push: I suspect the github context must contain the release tag so you'd be able to infer which folder to look things in

• side note: this workflow assumes that the latest thing we push is the version that reproschema-py should use. BUT if we have already published version 2.0.0 but we do a bug fix on an older version (say 1.0.1), then reproschema-py will be reset to the older 'fixed' version. I would say let's cross that bridge when we get to it but maybe we should mention that in a comment at the top of the yml so our future selves are not surprised if we run into this issue.

[Remi-Gau]

Other side note: are we considering that reproschema-py should in the future be able to validate using different versions of the reproschema?

[djarecka]

perhaps we should trigger this manually as we do with release and provide the version. That would add additional manual step, but perhaps solves a few issues

[yibeichan]

Other side note: are we considering that reproschema-py should in the future be able to validate using different versions of the reproschema?

good point. maybe validate the current version only. I mean, if every at-the-moment reproschema file is using the at-the-moment version and passes the validation, then, the future reproschema-py doesn't have to redo the validation for the past reproschema files. (hope it makes sense

[yibeichan]

if the suggested one doesn't work, maybe

LAST_VERSION=$(find releases -mindepth 1 -maxdepth 1 -type d -printf '%T+ %p\n' | sort -r | head -1 | awk '{print $2}' | sed 's|releases/||')

[yibeichan]

how about replacing
LAST_VERSION=$(ls -lt releases/ | grep ^d | head -1 | awk '{print $9}')
with the following

TARGET_DIR="releases"
URL="https://api.github.com/repos/${{ github.repository }}/contents/$TARGET_DIR?ref=main"
response=$(curl -sL -H "Authorization: token ${{ secrets.PERSONAL_ACCESS_TOKEN }}"  "$URL")
latest_version=$(echo $response | jq -r '.[0].name' | sort -rV | head -1)

[yibeichan]

Quick thoughts:

• maybe we could run this one when we do a github release rather than monitoring the release folder on push: I suspect the github context must contain the release tag so you'd be able to infer which folder to look things in

• side note: this workflow assumes that the latest thing we push is the version that reproschema-py should use. BUT if we have already published version 2.0.0 but we do a bug fix on an older version (say 1.0.1), then reproschema-py will be reset to the older 'fixed' version. I would say let's cross that bridge when we get to it but maybe we should mention that in a comment at the top of the yml so our future selves are not surprised if we run into this issue.

Can we specify that this one only runs when we have a release? Then both above concerns should be solved?

[djarecka]

Yes, we can, but I thought Remi point was that we might want to test outside the release cycle, so we might just do it similarly to release and ask for version in the input. In the future we could also ask for branch

…

On Thu, Jun 20, 2024, 9:36 AM Yibei Chen ***@***.***> wrote: Quick thoughts: - maybe we could run this one when we do a github release rather than monitoring the release folder on push: I suspect the github context must contain the release tag so you'd be able to infer which folder to look things in - side note: this workflow assumes that the latest thing we push is the version that reproschema-py should use. BUT if we have already published version 2.0.0 but we do a bug fix on an older version (say 1.0.1), then reproschema-py will be reset to the older 'fixed' version. I would say let's cross that bridge when we get to it but maybe we should mention that in a comment at the top of the yml so our future selves are not surprised if we run into this issue. Can we specify that this one only runs when we have a release? Then both above concerns should be solved? — Reply to this email directly, view it on GitHub <#519 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMV6GSR2MKMYSA4MFIDAT3ZILLFVAVCNFSM6AAAAABJSYIZJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBQG4ZDEMJUGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[yibeichan]

okay, so what's the decision here?

[djarecka]

seems like pre-commit is failing now...(but I also see this on main)

I will merge it to see if it works