CI: Automate building of Windows and macOS release binaries #20
Conversation
.ci/azure-pipelines/release.yml
Outdated
| rootFolderOrFile: build/install | ||
| includeRootFolder: false | ||
| archiveType: zip | ||
| archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.SourceBranchName)-$(MODE)-$(NESTING)-$(BUILD_TYPE)-$(OS_NAME).zip' |
There was a problem hiding this comment.
I am not sure I like the order for these. How about [...]$(BUILD_TYPE)-$(NESTING)-$(MODE)-$(OS_NAME).zip? I would also add an experimental label perhaps before the version name. For nesting, the word basic is a bit confusing as its meaning is not as immediate as it is for the other keywords. Could add basic-nesting but if you do that it may make sense to change the keyword separator to an underscore.
There was a problem hiding this comment.
Note that this follows the existing scheme we have. Examples are always better to illustrate things, so let's see...
The original is:
wrf-cmake-4.0-dmpar-basic-release-windows.zip.
Your suggestion:
wrf-cmake-4.0-release-basic_nesting-dmpar-windows.zip.
Hm, I'm not a fan of that. The idea was to group WRF-specific markers (nesting, mode) followed by generic markers (build type, os), in this order since the OS typically comes last.
So, I would leave the ordering, but I'm open to add _nesting to make it more clear what that means.
There was a problem hiding this comment.
OK with_nesting but not convinced with the current grouping. I would find it easier to find the binaries I want if they are grouped as suggested as all the releases would be grouped together. Having said that I haven't got a strong opinion on this so feel free to leave the order as it is.
There was a problem hiding this comment.
We're talking about different things I think. I look at a single filename, whereas you look at the whole list of filenames in the GitHub release assets, right?
Another option could be something like x64-linux-dbg and x64-windows-rel at the end of the filename, and everything else before, so you have all the "common" software markers at the end, and all WRF-specific things before that separate:
wrf-cmake-4.0-dmpar-basic_nesting-x64-linux-dbg.tar.xz
And maybe mode should come after nesting, since it's more related to the system:
wrf-cmake-4.0-basic_nesting-dmpar-x64-linux-dbg.tar.xz
There was a problem hiding this comment.
That's right. wrf-cmake-4.0-basic_nesting-dmpar-x64-linux-dbg.tar.xz is my preference. Since it's an extra 2 characters for debug and 4 for release you might as well be explicit with your naming of artefacts. Another addition is to add experimental before the version number:
wrf-cmake-experimental-4.0-basic_nesting-dmpar-x64-linux-debug.tar.xz
but that may be a bit too much... Just a thought.
There was a problem hiding this comment.
OK, let's go with that, and without experimental I would say.
|
Note: Do NOT merge yet, there is an issue with delocate on macos: https://dev.azure.com/WRF-CMake/WRF/_build/results?buildId=337 |
letmaik
changed the title
using gcc@8 for wrf together with netcdf-fortran (which links against gcc (=9)) meant we have two libgfortran's which delocate can't deal with.
|
Issue with macOS is solved now. |
This extends the Azure Pipelines scripts and adds a new "release" pipeline that when run on a git version tag will build the binaries, store them as build artifacts, and also upload them to a draft GitHub release, that then can be manually published.
Note: Linux is done manually for now and will be added at a later point.