Scripts and sync

[TheChymera]

I notice it's not entirely trivial to figure out what exactly we have in master. We need to lookup datetime and determine the most recent commit in upstream... Perhaps we should record the upstream hash in the commit message, interested in such a PR? To not over-sell the extent to which this is in sync with upstream, perhaps renaming master to nightly would be a good idea?

I also notice this hasn't run for a very long time. Should I set up a cron job on my server? if so I would need push access.

[yarikoptic]

We need to lookup datetime and determine the most recent commit in upstream...

make it output of

$> git describe --match=v[0-9].*.* `git log -1 --pretty=format:%H src/schema/`
v1.7.0-443-g54e79903

but take the exact release if git log -1 --pretty=format:%H points to a different release, which isn't the case now

$> git describe --match=v[0-9].*.*
v1.7.0-444-ga0512aaf

edit: added --match=v[0-9].*.*

but e.g. if we had it v1.7.1-111-... here. The point is that master might also correspond to the released version for a while (until changed). So -- would need a script and probably better to code it in python to simplify version comparison.

Should I set up a cron job on my server? if so I would need push access.

no personal servers... github action please. not an exact match but https://github.com/datalad/git-annex/blob/master/.github/workflows/update-mirror.yml could provide lots of cute steps. Eventually we might actually want to have it running within bids-specification itself (so may be let's do there right away) -- upon merge into master, possibly update here if needed (if no diff -- no need)

while at it - can even make it work for releases. E.g. if while processing specific commit with describe X.Y.Z+.. it would detect that we do not have X.Y.Z -- make a copy of that tag as well. Have a look at https://github.com/dandi/dandi-schema/blob/master/.github/workflows/release.yml#L83 we have for dandi . Overall, I feel for the above you just need a helper release_bids_schema <bids-specification-path> <bids-schema-path> which would be invoked in that workflow, and workflow might even want to checkout specific release tag per above or make it (or another workflow) react when tags are pushed (https://stackoverflow.com/questions/61891328/trigger-github-action-only-on-new-tags)

[yarikoptic]

I "got excited", here is a bash script which figures out which version to use for whatever sub-component of repo:

(git)lena:~/proj/bids/bids-specification[master]git
$> cat tools/version_component.sh
#!/bin/bash
#
# Provide list of components to come up with version for

set -eu

if [ -z "$@" ]; then
    # no components given -- just 
    comm=HEAD
else
    comm=$(git log -1 --pretty=format:%H "$@*")
fi

cver=$(git describe --match=v[0-9].*.* "$comm")
ver=$(git describe --match=v[0-9].*.*)

# clean versions without possible git commits

if [ "${cver%%-*}" == "${ver%%-*}" ]; then
    out_ver="$cver"
else
    out_ver="${ver%%-*}"
fi

# make it more "semver" with using build marker although should not be used for comparison
out_ver="${out_ver/-/+}"
out_ver="${out_ver/v/}"

echo "DEBUG: cver=$cver ver=$ver out_ver=$out_ver" >&2  # for debugging
echo "$out_ver"

so it gives now:

(git)lena:~/proj/bids/bids-specification[master]git
$> tools/version_component.sh src/schema
DEBUG: cver=v1.7.0-443-g54e79903 ver=v1.7.0-444-ga0512aaf out_ver=1.7.0+443-g54e79903
1.7.0+443-g54e79903

$> git co v1.7.0
...
(git)lena:~/proj/bids/bids-specification[tags/v1.7.0^0]git
$> tools/version_component.sh src/schema
DEBUG: cver=v1.6.0-480-ge47283a2 ver=v1.7.0 out_ver=1.7.0
1.7.0

so seems to work nicely -- use it, no python needed ;)