I’m reaching out with a question regarding the use of ropensci repositories on GitHub Codespace. Recently, I encountered an issue while debugging one of my R packages, osmextract (see details here). This required building GDAL 3.10 from source, which I’m not very experienced with, so I used the sf package’s Dockerfile as a base in GitHub Codespace.
To replicate this environment, I added a simplified version of the sf Dockerfile to the .devcontainer folder in my ropensci/osmextract repository (see here). However, I noticed that the GitHub Codespace build process seems to ignore this custom Dockerfile for reasons I can’t figure out. Interestingly, this issue doesn’t occur when I use a repository in my personal account (example here).
Are there any known restrictions on using custom Dockerfiles in ropensci repositories on GitHub Codespace? I’d be grateful for any insights or suggestions.
Thank you in advance, and I’m happy to provide further details if needed.
I’ve just increased your access rights through the ropensci/osmextract team to “admin” and removed your directed access, as maybe that could help? (In the end it means you still have admin access but in a tidier way)
Unfortunately that didn’t help, and it still looks like the creation process ignores my .devcontainer file (which is recognised when I create a codespace inside a personal repository). Maybe I should ask this question to GH people? Do you have any suggestion?
Ah too bad. Several of us on the team read this conversation but none of us has any further idea, so yes contacting GitHub sounds like a good idea. Please tell us what you learn, and how we can help! Good luck!
To follow up on this discussion, ckanr now has a working devcontainer setup.
Why: While developing ckanr as an R package is fairly straight forward, having a running CKAN instance is not, and choosing between different CKAN versions or distributing test credentials across collaborators and contributors is difficult.
How: ckanr’s devcontainer setup spins up a CKAN instance with all required microservices via a docker-compose file. The CKAN version can be selected in an .env file (requires devcontainer rebuild). CI tests against all supported CKAN versions in parallel and runs on pull requests.
So far, the cost is carried by the individual GitHub user, not rOpenSci.
Happy to discuss further and share lessons learnt!
Thank you very much @florianm and I’m really sorry that I’ve never replied to your previous message… Anyway, I’m happy that you figured it out
I checked your repo (thanks again) and I noticed that, actually, there was a typo in the way I set up the container (i.e. I used .devcontainer.json instead of devcontainer.json). Now it’s working fine also inside my repo.
Just to round this up - ropensci/ckanr: R client for the CKAN API now has a working devcontainer setup with a choice of CKAN versions 2.9 - 2.11 (via .devcontainer/.env).
CI runs a matrix of these CKAN versions in parallel, whereas for local development in Codespaces or VS Code the devcontainer needs to be rebuilt with different CKAN versions (comment in/out sections in .env).
There was a lot of trial and error, and the current setup follows an older version of ckan/ckan-docker’s docker compose file (which itself has matured nicely into a much more involved setup).
If anyone wants to take it for a spin, feel free to launch your own Codespace (best in a local VS Code) from the ckanr repo > Code > Codespaces or directly via Sign in to GitHub · GitHub.
