At the time the GeoServer project does not have financial resources and man power to stand up a Windows build server (if you can help with this, please contact the developer list)
if this is no longer true please disregard
if build server still required
i happen to know that as an open source project the geoserver project can run unlimited builds in azure devops. so can anyone else who clones the repo in a public azure devops project
after investigating the geoserver github actions i saw nothing incompatible with triggering builds in azure devops in collaboration with specific github actions
the primary showstopper risk seems to revolve around headless installation of nsis itself and its dependencies on azure build servers as per
extract the .DLL files (AccessControl.dll) and copy it to the NSIS plugins directory usually C:\Program Files\NSIS\Plugins\x86-ansi
if build server still required and mitigations exist for installing nsis and dependencies on cloud build agents, i offer to
evaluate the full build process for the windows geoserver
deliver a proof of concept of a suitable pipeline that runs in azure devops
no signing of the distribution with an apple developer certificate → if signing required details are required on how this is currently accomplished
mac_installer.sh is the workflow entrypoint for building a macos distribution
no macos build server required
if the above assumptions are true builds can be accomplished at will in azure devops as follows
ensure an organization in azure devops
ensure a public project to host the build, ensuring open source sla which is unlimited builds
create a pipeline that can clone the required assets from github
ensure a linux build agent
add a script task to the pipeline initialized to the location required by mac_installer.sh
ensure pipeline auth to the upload location
ensure pipeline artifact versioning
ensure permissions and pipeline triggers
if no personpower is available to accomplish these tasks certainly i can make those things happen
these are some pipelines i currently operate in azure devops - the target environment is kubernetes, the artifacts are npm and nuget packages and python whatevers and docker images, with an expectation that the customer may want to operate a geoserver instance in the cluster, hence my interest
on the matter of task ‘ownership’ i would suggest that if there is a corporate entity associated with producing geoserver builds, that entity should own the azure devops organization to accrue the benefits of the open source azure devops sla, and delegate permissions to whoever is going to accomplish the above tasks
At the time the GeoServer project does not have financial resources and man power to stand up a Windows build server (if you can help with this, please contact the developer list)
if this is no longer true please disregard
if build server still required
i happen to know that as an open source project the geoserver project can run unlimited builds in azure devops. so can anyone else who clones the repo in a public azure devops project
after investigating the geoserver github actions i saw nothing incompatible with triggering builds in azure devops in collaboration with specific github actions
the primary showstopper risk seems to revolve around headless installation of nsis itself and its dependencies on azure build servers as per
extract the .DLL files (AccessControl.dll) and copy it to the NSIS plugins directory usually C:\Program Files\NSIS\Plugins\x86-ansi
if build server still required and mitigations exist for installing nsis and dependencies on cloud build agents, i offer to
evaluate the full build process for the windows geoserver
deliver a proof of concept of a suitable pipeline that runs in azure devops