-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish selfcontained Artifacts #219
Comments
Hey @enzian, thanks for raising this. Out of interest, do you currently have a use case for this? |
Yes, we have repositories that contain documentation which is versioned. We could use minver to publish this documentation versioned! |
@enzian how would you actually do that? Would you have some kind of CI build to publish when pushing a tag? |
@adamralph yes, this feature would make sense in CI build environments! |
@enzian given that you're doing other .NET work, do you not already have the .NET SDK installed on your build agents? |
Well I'm not only doing .net work! |
@enzian sure, I wasn't suggesting otherwise. 😉 But do you actually have the situation where you would like to use a CI system to publish these docs but the relevant agents/images/etc. do not have the .NET SDK installed? |
I'm actually using hosted agents that are created on demand and have absolutely nothing if I don't bring it ;-) |
OK, so now I believe you that you have a valid use case. 😉 I'm not opposed to this if it doesn't add too much maintenance burden. I guess we'd have to build several versions for different platforms and publish them somewhere? |
Yes, because each self-contained deployment would only work for the RID specified, Then, you'll have to manage acquiring and extracting them on your CI systems, likely with manually written code/scripts. Or you can get the .NET Core SDK for the machine, and do a tool install, and then you have the CLI tool readily available. On Linux systems, acquiring the SDK is trivial since it's available through package managers, and it's not that much more difficult to get for other OSes. Personally, it sounds like getting the SDK and installing the command line tool is less work for everyone. Also, exposing the command line tool as a separate artifact instead of keeping it internal does also complicate doing #112 when it makes sense. |
Thanks @bording. Some good arguments there.
I assumed that, if this goes ahead, it would be an alternative way of distributing the CLI tool, which is already public. |
Fair enough, though I suspect you'd likely end up needing a separate project in the solution for it regardless. |
Yeah, that's probably true. But in any case, before going any further with this, I need to be convinced, as per your arguments above, that getting the self-contained artifact onto the build agents is easier than getting the .NET SDK and installing |
My approach would be to add a build pipeline on azure devops that builds the cli project for multiple targets, zip all of them and drops them into the respective github release! This means, that if I want to use it, i can just wget/curl, unzip and be done! That seems much easier to me then downloading the entire SDK (which takes time and time is an issue when building...) then downloading the tool, which takes time again, not to speak of the disk space and traffic used in this whole process! So, it takes fewer steps and takes less time and resources.
That is not the case: You can either build all your targets by adding them to the .csproj or by adding them to the build/publish commands of the dotnet cli. This will then build the self-contained packages and drop them in a folder with their target mnemonic! |
@enzian as I understand it, the self-contained apps will also contain the entire .NET Core runtime. Is that the case? I want to be sure there is enough benefit to offset the extra maintenence burden. Bear in mind that right now the Azure pipelines build only exists to serve as a smoke test for the pipelines specific console pallette. The Appveyor build is the CI build. I'd prefer to keep everything in the build script rather than have CI server config performing specific parts of the build. Also bear in mind that there are no GitHub releases currently. The only release is to NuGet. |
yes, some you don't need are stripped out though. I tested this quickly: Building minver to as a self contained artifact makes for a 75Mb package. The dotnet core sdk (2.1.something) is ~210 Mb and that's not counting the nuget dependencies that need to be pulled additionally! I know, that 75Mb sounds huge but considering it contains everything needed for running a tool and can be downloaded as one file with a single HTTP GET as opposed to installing 200Mb of sdk and pulling in dozens (or much more) nuget packages is not exactly more efficient and definitely takes more time! On hosted build agents, time = money, storage is not an issue! PS: As a side note because I know it's not ready yet: using IL-Linker when publishing I'm able to decrease this to about 30Mb!
Built like this, the self-contained CLI comes in at 38Mb. |
oh and, BTW: I don't want to be the guy that annoys everyone with his craziness: So if this is too much - a "thanks but no thanks" is fine for me ;-) |
Not at all @enzian. 🙂 I'm simply weighing up the pros and cons of this. At the moment I'm seeing: Pros
Cons
Am I missing anything? |
Not really!
is not really an issue, since all targets could be built in parallel and:
is basically one change in one csproj xml node. I'm OK, not going down this road, and if I really want it, I can still do this myself ;-) Do we close? |
@enzian I'm not opposed to doing this as long as the added maintenance burden is acceptable.
Could you please send a PR demonstrating this? Regarding releasing, it looks like I can set up a GitHub releases deployment in Appveyor to do it, so that should be a low burden. |
If you wanted to support all the operating systems with these self-contained builds that you can with the existing tool, you'll have to account for the fact that LibGit2Sharp has a native dependency, and provide a separate build for each of them. At the moment, that would mean you'd need:
And it would be on the consumers of these self-contained builds to understand the RID fallback graph so they know which of them to use based on the linux distro they're using. That list also changes over time, so that would have to be maintained as well. |
@bording: that is very much true, and something I have not really considered! Maintaining this would either mean to limit the targets the minver project provides binary packages for (say for example We also lack the manpower to ensure the provided artifacts actually work on all platforms... |
So if I understand correctly, building native packages for all these platforms would be quite involved, yes? |
Yes, the question is, if this outweighs the advantages... |
@enzian OK, thanks. In that case, I'll go ahead and close it. We can always re-open if the requirement comes up again. |
Since the CLI is a since self-contained little tool, it could be published as a self-contained app and be used also in environments where the .net core runtime is not installed. This would enable the use of minver in other language/build environments outside of .net!
Information of how to build self-contained artifacts can be found here and a sample with docker here.
To use minver in other environments #214 would be something useful, since parsing stdin, stdout and stderr is quite fiddly and having a structure where all relevant versioning information is kept would be helpful!
The text was updated successfully, but these errors were encountered: