If supporting them can come at minimal or zero cost, I don't see why not. As stated before, this is already achieved within CircleCI, so I guess now it's up to either integrating that within Apache infra, or replicating elsewhere. I'm checking out appveyer too. At some point, though, I'd really appreciate some guidance into what direction(s) would be acceptable, before I've tried every CI service available.

-d


On April 27, 2020 21:44:29 Dominik Psenner <[email protected]> wrote:

Mileage may vary, but I see no point in supporting ancient frameworks.
Better support only few valuable targets well and offload maintenance
efforts to whoever needs other targets that are hard to support. For
instance, whoever builds against client profile could fork and build
log4net from source. Patches to make it work are valuable and always
welcome, now and anytime in the future. Those patches may not be mergable
into develop/master either as they could live in their own branch if
necessary.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Apr 27, 2020, 21:13 Davyd McColl <[email protected]> wrote:

Thanks, I've already tried using mono for cross-compilation, but older
targets (and specifically client profile) make this option a bit of a
non-starter. I got it mostly working, but mostly isn't all the way.

CircleCI provides a good build environment, which I'm probably going to
try
to replicate in docker, though that would still require a windows host.

-d


On April 27, 2020 21:07:50 Dominik Psenner <[email protected]> wrote:

> 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]>
>>





Reply via email to