Hi there -- I have a Carpentries training module that depends on duckdb and installs the package on a Github runner image to generate the online version. However the relatively recent addition of the xz compressed source directory seems to be breaking the Github actions that orchestrate this process. See the log here:
https://github.com/carpentries-incubator/bioc-scrnaseq/actions/runs/12036979601/job/33559404345#step:6:2590
By the time it gets to tar cvJf duckdb.tar.xz duckdb that directory seems to be gone. I guess it's deleted early somehow, maybe it's the cleanup script somehow running before configure or something? It's hard to tell exactly what's going on, but it does seem to be a relatively recent bug as another workflow from a few weeks ago that used duckdb_1.1.2 from CRAN succeeded.
Maybe this is my workflow's problem, but I thought I would flag the issue here since it was pretty tricky to track down. It would be nice not to have to pin the module to an old duckdb version.
Hi there -- I have a Carpentries training module that depends on
duckdband installs the package on a Github runner image to generate the online version. However the relatively recent addition of the xz compressed source directory seems to be breaking the Github actions that orchestrate this process. See the log here:https://github.com/carpentries-incubator/bioc-scrnaseq/actions/runs/12036979601/job/33559404345#step:6:2590
By the time it gets to
tar cvJf duckdb.tar.xz duckdbthat directory seems to be gone. I guess it's deleted early somehow, maybe it's the cleanup script somehow running before configure or something? It's hard to tell exactly what's going on, but it does seem to be a relatively recent bug as another workflow from a few weeks ago that usedduckdb_1.1.2from CRAN succeeded.Maybe this is my workflow's problem, but I thought I would flag the issue here since it was pretty tricky to track down. It would be nice not to have to pin the module to an old
duckdbversion.