As apache folks, we have the benefit of sponsored msdn subscriptions and thus some sponsored computing time in azure. May that be an option?
I dont know about the tasks involved. I can also think of cross compiling on ubuntu inside docker by leveraging dotnet-sdk and linking against the reference assemblies shipped with mono or other requirements that can be provided with Dockerfile's, github actions or other build infrastructure. This [1] is a reference project that works and may serve as a minimalistic sample that, to be honest, is pure net core/netstandard and therefore lacks mono. [1] https://github.com/dpsenner/event-sorcery -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Mon, Apr 27, 2020, 16:48 Matt Sicker <[email protected]> wrote: > Looks like AppVeyor is another option. Is that comparable to CircleCI? > > (For context, I'm mostly familiar with Jenkins as I work on that > project at $dayjob) > > On Mon, 27 Apr 2020 at 09:36, Matt Sicker <[email protected]> wrote: > > > > Seems like I missed some other services: > https://infra.apache.org/services.html > > > > If nothing on there is appropriate, I think we need to create a Jira > > ticket in https://issues.apache.org/jira/browse/INFRA > > > > On Mon, 27 Apr 2020 at 01:28, Davyd McColl <[email protected]> wrote: > > > > > > What would need to be done to make other CI systems talk with Apache > Infra? > > > > > > I ask because I've spend around a day now trying to convince Travis CI > to build log4net successfully, without a lot of joy, particularly because > the Travis Windows build environment is quite out of date, having been > launched as a beta service in 2018, with tooling from 2015. I can get > vs2019 installed via chocolatey packages, which solves most of the > requirements, but haven't had joy in getting .net 3.5 to install on the > build machine yet, resulting in predictable build failures. In addition, > the installation of vs2019 tooling adds a few minutes to build. > > > > > > In contrast, build at CircleCI has been simple, quick, and, best of > all, works. I've also figured out artifact publishing, so, with the > addition of some scripting, one possible solution might be for an Apache > Jenkins build job to simply download the nuget package from CircleCI and > publish it -- meaning that Apache nuget keys don't have to leave secure > premises, which is a good thing (: For example, a parameterised build which > is given only a build number could be manually kicked off when a release > has been approved by all involved. This build could download the .nupkg > from CircleCI and publish to nuget.org. > > > > > > If this (or something similar) seems like a viable option, I may be in > a position to raise a PR (after cleaning up some git history -- I probably > have 50 or 100 commits which are only attempts at getting TravisCI to build > with varying approaches. > > > > > > -d > > > On 2020-04-25 22:15:36, Matt Sicker <[email protected]> wrote: > > > The only external build systems that are set up for Apache right now > > > are Travis and some limited GitHub Action experiments. Other CI > > > systems may need to talk with Apache Infra. > > > > > > On Sat, 25 Apr 2020 at 14:47, Davyd McColl wrote: > > > > > > > > Thanks for the reply (: > > > > > > > > Would external build systems like circleci be acceptable too? > > > > > > > > -d > > > > > > > > > > > > > > > > On April 25, 2020 21:03:01 Matt Sicker wrote: > > > > > > > > > Info about our existing infra is documented here: > > > > > https://cwiki.apache.org/confluence/display/INFRA/Jenkins > > > > > > > > > > On Sat, 25 Apr 2020 at 13:38, Davyd McColl wrote: > > > > >> > > > > >> Hi > > > > >> > > > > >> Quick question: what operating system does the available CI > server run? > > > > >> Even if docker is an option, the host system is matters. > > > > >> > > > > >> Thanks > > > > >> -d > > > > >> > > > > >> > > > > > > > > > > > > > > > -- > > > > > Matt Sicker > > > > > > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > -- > > Matt Sicker <[email protected]> > > > > -- > Matt Sicker <[email protected]> >
