-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor parameterize #65
refactor parameterize #65
Conversation
philvarner
commented
Nov 22, 2023
•
edited
Loading
edited
- Build is now configured with a patch version release (e.g., 3.8.0) instead of a commit hash, but still publishes an image tagged with just the minor version (e.g., 3.8).
- CI action versions updated.
- Dockerfile renamed to Dockerfile, since we'll only support one GDAL version at a time
@vincentsarago what do you think about building this way? I don't think it's perfect because it requires the dependencies to be updated across all gdal versions that are being built, but I think it's simpler and more maintainable than having one build that duplicates most everything for each gdal version |
This ran locally for me using 3.8.0, but ci seems to have failed because the server for one of the dependencies was down when it built. |
@philvarner thanks for starting this. To be honest I'm not quite sure we need to support multiple I will agree supporting 3.8 and 4.0 in parallel but we can take care of this when it will be released (the build of 4.0 will be quite different which mean we will need specific dockerfiles for each version) |
Okay, sounds good. I'm going to create another PR to update this to use 3.8 then. |
I refactored this one instead. This is configured with a patch version release (e.g., 3.8.0) instead of a commit hash, but still publishes an image tagged with just the minor version (e.g., 3.8). |
@vincentsarago ready for review |
🚢 |
FYI GDAL config log
|