Provide pre-compiled binaries from the console app together with releases

[johnnyasantoss]

Maybe use Azure Pipelines, Travis or Github actions to build an executable for the three main platforms (Win, Linux, Mac).

I'm working on script to publish a single-file as the time of writing this issue. See PR #476

[vslee]

Now that the console app accepts more standardized parameters, it makes sense to publish a standalone executable. @jjxtra is already using Azure pipelines for testing builds, so he may want to incorporate building an executable into that pipeline as well. Otherwise, Traves or Github actions are good alternatives as well.

[jjxtra]

I vote github or azure. Not a fan of Travis. How often do we want to build a release? Once a week? Month? Probably not daily...?

[vslee]

If we go with Azure, we can use the triggers to build per PR instead of on a schedule (daily/weekly). Looks like Azure artifacts includes 2GB free, and these builds are pretty small so it would be pretty much impossible to max it out. This would be the prerelease artifact.
We could also have a second artifact that builds out every time we push out an official release.

[johnnyasantoss]

I vote github or azure. Not a fan of Travis. How often do we want to build a release? Once a week? Month? Probably not daily...?

Well, I think all of them are good.
One thing to have in mind, is that to publish a R2R Single file distribution of our console app, we would have to build the binaries for each platform in a matching OS i.e. build win-x64 on a Windows worker, linux-x64 on a Linux worker, osx-x64 on a Mac worker.

With that in mind I think that we can go with Azure. I think it's the only one that provides these three platforms.

Now about the time period, I think that it just needs to be built with every new git tag (so, every new GH release) and then have a monthly release with minor fixes and major releases on a manual basis.
It would also help in these situations #480, making the publication of this package more consistent :)

Would that be sufficient?

[jjxtra]

Works for me!

On Mon, Nov 11, 2019 at 4:20 AM Johnny A. dos Santos < ***@***.***> wrote: I vote github or azure. Not a fan of Travis. How often do we want to build a release? Once a week? Month? Probably not daily...? Well, I think all of them are good. One thing to have in mind, is that to publish a R2R Single file distribution of our console app, we would have to build the binaries for each platform in a matching OS i.e. build win-x64 on a Windows worker, linux-x64 on a Linux worker, osx-x64 on a Mac worker. With that in mind I think that we can go with Azure. *I think it's the only one that provides these three platforms.* Now about the time period, I think that it just needs to be built with every new git tag (so, every new GH release) and then have a monthly release with minor fixes and major releases on a manual basis. It would also help in these situations #480 <#480>, making the publication of this package more consistent :) Would that be sufficient? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWQGCMMSTDXU2OYXXZQDLQTE5XHANCNFSM4JKWGC4A> .

-- -- Jeff

[vslee]

What is a R2R file?

[vslee]

nm I found it:

ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation.
R2R binaries improve startup performance by reducing the amount of work the JIT needs to do as your application is loading. The binaries contain similar native code as what the JIT would produce, giving the JIT a bit of a vacation when performance matters most (at startup). R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios, and the native version of the same code, to improve startup.
R2R is supported with .NET Core 3.0. It cannot be used with earlier versions of .NET Core.

Sounds good. Can you help us set up these Win/Linux/Mac workers?

[johnnyasantoss]

@vslee Yeah sure :)
I just need to set up a CI for one of my forks and play around with it then I'll add the scripts to my last PR (#476).

[jjxtra]

If we need more storage in Azure I'm happy to ping them see if they will upgrade us, or I'll just pay for it :)

[vslee]

If, in the process of trying out Azure, you find that Github actions/artifacts are a better way to go, we can do that as well.

[jjxtra]

So an azure pipeline could publish binaries to a github release artifact?

[vslee]

Sorry, that's not what I meant. I mean that if in the process of trying to build the Azure pipelines, he finds that Aithub Actions is easier to use, we can use that instead and publish binaries to Github Artifacts.

[johnnyasantoss]

So an azure pipeline could publish binaries to a github release artifact?

@jjxtra Yep, that is possible and its what I did in this PR #476

Sorry, that's not what I meant. I mean that if in the process of trying to build the Azure pipelines, he finds that Aithub Actions is easier to use, we can use that instead and publish binaries to Github Artifacts.

@vslee I already used Azure Pipelines before, so I didn't even try Github Actions 🤔 Maybe in the future I can try to find time to learn its GH Actions script/schema

[vslee]

@vslee I already used Azure Pipelines before, so I didn't even try Github Actions 🤔 Maybe in the future I can try to find time to learn its GH Actions script/schema

No need, if the Azure Pipelines works out.