Runtime: Enable Pipeline build support for Linux armel (Tizen)

[hqueue]

Enable Pipeline build support for Linux armel (Tizen) and publish packages.

[hqueue]

@gkhanna79 Is there any update for the pipeline build of Tizen (armel) ?

[gkhanna79]

@hqueue Sorry for the delay - I was heads down with few other things that needed to complete. Yes, I have had chance to think about this and had few questions that I was hoping you can help answer. Also, please correct me wherever applicable.

• For shipping Tizen, are you planning to take a snapshot of .NET Core 2.0 repos (CoreCLR/CoreFX/Core-Setup), once 2.0 ships, and build the corresponding binaries that become part of the Tizen release? Or, will you be consuming .NET Core 2.0 binaries, restore required packages for Tizen RID and build the Tizen framework for it?

• Once Tizen ships, how would you service the binaries if you consume the ones (produced for Tizen RID) by our engineering system? Will your servicing be dependent upon .NET Core 2.0 servicing schedule?

• If you were to be able to build the .NET Core 2.0 product (CoreCLR/CoreFX/Core-Setup) using a single command that would result in producing all the required packages that you need for Tizen product, would that be helpful for you in the upcoming Tizen release? Also, do you think it will enable you to be more efficient in your build/test/servicing needs?

I am presuming that you have infrastructure to run tests at your end to validate the product - please do correct me if my assumption is incorrect.

CC @Petermarcu @richlander @shawnro

[hqueue]

@lemmaa @jyoungyun Let's have a discussion about this.

@gkhanna79 Not everything is decided yet. I will leave a reply after discussion.

[hqueue]

@gkhanna79

• For shipping Tizen, are you planning to take a snapshot of .NET Core 2.0 repos (CoreCLR/CoreFX/Core-Setup), once 2.0 ships, and build the corresponding binaries that become part of the Tizen release?

Right, we (1) take a snaphot of .NET Core 2.0 repos and (2) build it in Tizen build infra and (3) will ship Tizen which also contains .NET Core 2.0 on devices.

Or, will you be consuming .NET Core 2.0 binaries, restore required packages for Tizen RID and build the Tizen framework for it?

This is also right. Visual Studio Tools for Tizen (https://blogs.msdn.microsoft.com/visualstudio/2017/02/01/samsung-releases-second-preview-of-visual-studio-tools-for-tizen/) will restore .NET Core 2.0 binaries with Tizen RID.

• Once Tizen ships, how would you service the binaries if you consume the ones (produced for Tizen RID) by our engineering system? Will your servicing be dependent upon .NET Core 2.0 servicing schedule?

As described above, Visual Studio Tools for Tizen will restore packages with Tizen RID and eventually I expect these packages might be available from the official nuget server after .NET Core 2.0 release with pipeline build. Right? Therefore I think it is definitely dependent on .NET Core 2.0 servicing schedule.

• If you were to be able to build the .NET Core 2.0 product (CoreCLR/CoreFX/Core-Setup) using a single command that would result in producing all the required packages that you need for Tizen product, would that be helpful for you in the upcoming Tizen release? Also, do you think it will enable you to be more efficient in your build/test/servicing needs?

Yes, it may be helpful to reduce our burden when migrating .NET Core to Tizen.
However, it may depend on the implementation you are suggesting, because there are many difficulties in addition to sepreated build of each repo, e.g. cycle dependencies, downloading build tools and etc.

I am presuming that you have infrastructure to run tests at your end to validate the product - please do correct me if my assumption is incorrect.

Right we have our own infrastructure to build and validate our product for Tizen and this is for Tizen release. And for .NET Core 2.0 release for Tizen, we are waiting for official pipeline build you are working on, including daily build.

I hope I've answered your questions, however if you have more inquiries, feel free to ask us :)

Also there are some concerns we have in mind with above scenario and we will post it again when we finish listing concerns.

BTW is there anything we have to prepare for .NET Core 2.0 release for Tizen ? For example, is there any Test scenario for verifying .NET Core before release other than passing unittests in coreclr and corefx ?

Let us know, if there is anything we can help :)

[jyoungyun]

@gkhanna79 Regarding above comments, we have some concerns about shipping .NET Core in Tizen.

First, in tizen, .NET Core will build and ship in our infrastructure after taking a snapshot from github code, and then when user develop their application, they use Visual studio by restoring .NET Core 2.0 nupkgs. At this time, nupkg used in the development of the app is the same as the code snapshot we shipped with .NET Core, but the build location is not the same, Runtime build in our infrastructure and Application build in Visual studio tool. Is there any concern in this area?

And secondly, if the .NET Core needs to be modified even after the Tizen target is released, we will redistribute it by applying only the fix patch from the existing code after the snapshot. Are there any issues with signing or security issues in this scenario?

[jyoungyun]

@gkhanna79 And.. When can you publish Tizen nupkgs to myget server? I want to test restoring tizen nupkg with our rid by using latest sdk. If there is some error, we need to reflect it before .NET Core 2.0 release. Could you let me know the schedule?

[gkhanna79]

Visual Studio Tools for Tizen (https://blogs.msdn.microsoft.com/visualstudio/2017/02/01/samsung-releases-second-preview-of-visual-studio-tools-for-tizen/) will restore .NET Core 2.0 binaries with Tizen RID.

@hqueue Will the nuget packages being used to restore the binaries for VS Tools for Tizen be also built in the Tizen build infra that you mention above? If not, is there a specific reason for that given that the build you do in Tizen build infra will produce them anyways.

I expect these packages might be available from the official nuget server after .NET Core 2.0 release with pipeline build. Right? Therefore I think it is definitely dependent on .NET Core 2.0 servicing schedule.

Possibly decoupling this specific dependency is what this discussion is about. If Tizen build infra can produce the nuget packages, which you then publish to your own specific feed (e.g. a Tizen specific feed on myget), then you will not have this dependency on our engineering infrastructure or release schedule. You can, ofcourse, choose to pick fixes made into our release branches and port them into your release branches, as you desire, and yet be independent in terms of your own release and servicing schedule.

And for .NET Core 2.0 release for Tizen, we are waiting for official pipeline build you are working on, including daily build.

Based upon what I mentioned above, I would assume that whatever you end up building in Tizen build infrastructure and releasing (and publishing to Nuget) would be the .NET Core 2.0 for Tizen, built, validated, signed off and serviced by you, without any dependency on us.

@jyoungyun The concerns you raised are the ones I had, in addition to figuring out how we can enable you to be more independent and self-contained for all scenarios. I believe both your concerns should get addressed by what I propose above, which I summarize below:

1) Tizen build infrastructure produces the binaries that are shipped on Tizen devices and nuget packages that will eventually be published to Nuget.

2) VS Tools for Tizen will use the nuget packages produced in (1) above and thus, will use the same set of binaries that were shipped on devices and hence, always are in sync.

3) Tizen servicing will be done in your own servicing branches, by cherry-picking fixes from our servicing branch as you deem appropriate. Ofcourse, if you find a bug that has not been fixed in our servicing branches, we would look forward to you contributing the fix to our servicing branch and then flowing it yours :)

I believe with the above approach, by enabling Tizen build infrastructure to produce the nuget packages and publishing them to nuget, you will have complete autonomy over your release, schedule, servicing and consistency of the product across the board - and not have any dependency on us that could block you.

What do you think?

[jyoungyun]

@gkhanna79 Thanks for kindly reply. :)

If we can take the build system separately, it looks like a way. However, I think that it is necessary to examine whether there is not any problem at this time. Once we discussed with our team guys, the some issues are summarized as follows.

First of all, I want to clear what we need nupkgs for .NET Core SDK release. And then I want to check if all of nupkgs we need can build in our infrastructure or not.

For .NET Core:
**coreclr**
Microsoft.NETCore.Jit.2.0.0-beta-25014-0.nupkg
runtime.tizen.4.0.0-armel.Microsoft.NETCore.Jit.2.0.0-beta-25014-0.nupkg
Microsoft.NETCore.Runtime.CoreCLR.2.0.0-beta-25014-0.nupkg
runtime.tizen.4.0.0-armel.Microsoft.NETCore.Runtime.CoreCLR.2.0.0-beta-25014-0.nupkg
**corefx**
Microsoft.NETCore.Platforms.2.0.0-beta-25015-0.nupkg
Microsoft.Private.CoreFx.NETCoreApp.4.4.0-beta-25015-0.nupkg
runtime.tizen.4.0.0-armel.Microsoft.Private.CoreFx.NETCoreApp.4.4.0-beta-25015-0.nupkg
**core-setup**
Microsoft.NETCore.DotNetAppHost.2.0.0-beta-001650-00.nupkg
runtime.ubuntu.16.04-arm.Microsoft.NETCore.DotNetAppHost.2.0.0-beta-001650-00.nupkg
Microsoft.NETCore.DotNetHost.2.0.0-beta-001650-00.nupkg
runtime.ubuntu.16.04-arm.Microsoft.NETCore.DotNetHost.2.0.0-beta-001650-00.nupkg
Microsoft.NETCore.DotNetHostPolicy.2.0.0-beta-001650-00.nupkg
runtime.ubuntu.16.04-arm.Microsoft.NETCore.DotNetHostPolicy.2.0.0-beta-001650-00.nupkg
Microsoft.NETCore.DotNetHostResolver.2.0.0-beta-001650-00.nupkg
runtime.ubuntu.16.04-arm.Microsoft.NETCore.DotNetHostResolver.2.0.0-beta-001650-00.nupkg

For .NET Core SDK:
** core-setup **
Microsoft.DotNet.PlatformAbstractions.2.0.0-beta-001650.nupkg
Microsoft.Extensions.DependencyModel.2.0.0-beta-001650.nupkg
**sdk**
Microsoft.NET.Sdk.2.0.0-alpha-00000001-01.nupkg
**NuGet.Client**
?

Is there any nupkg missing for .NET Core release from the list above? Please let me know. The things that coreclr, corefx and core-setup generate can be built by ourselves. But for other nupkg we need to make sure we build it ourselves or we can use the file you created.

The situation I am worried about is as follows.
For example, if some nupkg we are trying to create has a dependency of Tizen runtime, and it can not build in our build infra, you must use the output we build when building in MS build infra. I saw some nupkgs which have different implementation per tfm. And we are also considering the case where tizen tfm needs to take another implementation. So, are there any files we can not build that depend on Tizen runtime nupkg? If so, can you build it using our output in MS build infra?
And in this case, is it okay if we are ready first when Microsoft .NET release? (MS .NET release has a dependency on us.)

And another question, if we have a seperate build system, we need to publish nupkgs at the same time, at the same version id. How can we sync with? Is there any infra to trigger us? Or do you give us some permission to access MS build infra system?

Tizen servicing will be done in your own servicing branches, by cherry-picking fixes from our servicing branch as you deem appropriate. Ofcourse, if you find a bug that has not been fixed in our servicing branches, we would look forward to you contributing the fix to our servicing branch and then flowing it yours :)

I want to know what your own sevicing branch does mean. We do not have a separate branch for .NET Core. We have a special repository in Tizen, but this is merely a way to get the github code to tizen. We do not have a plan to patch or contribute here. It will always be 100% sync with .NET Core code in github.

Please let me know if I am wrong or If I missed some part. By the way, we started to work on Tizen nupkg job 3 months ago, but if you were planning to run a separate system, it would be nice to talk about it in advance. As you know, the 2.0 release is soon, and if we decide to build a separate build system, I'm not sure we can do it on schedule.

Anyway, Have a nice weekend and see you next Monday!

[hqueue]

@jyoungyun Thank you for summarizing discussion.

@gkhanna79 In addition to comment by @jyoungyun, my another simple question is that is it possible to publish a binary which will be appeared on daily build page at https://github.com/dotnet/core-setup#daily-builds when using separated Tizen build infra. I think @jyoungyun raised similar concern regarding publishing nupkgs.

[gkhanna79]

@jyoungyun Your list looks correct with respect to .NET Core nuget packages. Few comments:

• Core-Setup also produces DependencyModel and PlatformAbstractions nuget packages. You should consider them in the .NET Core list of nuget packages and not .NET Core SDK.

  • I agree that you can build the packages listed under .NET Core above, in Tizen Build infrastructure and the list above looks correct to me.

But for other nupkg we need to make sure we build it ourselves or we can use the file you created.

What other packages do you have in mind? The only one that comes to my mind is libuv - do you use it for Tizen (BTW, it has been removed from Microsoft.NETCore.App for 2.0, so it won't be a dependency for you to worry about if you do not use it)? Also, as long as the additional packages you depend upon _do not_ have native components in them, you will not need to build them and can use what we produce. Let me know if this is not correct.

For example, if some nupkg we are trying to create has a dependency of Tizen runtime, and it can not build in our build infra, you must use the output we build when building in MS build infra. I saw some nupkgs which have different implementation per tfm. And we are also considering the case where tizen tfm needs to take another implementation. So, are there any files we can not build that depend on Tizen runtime nupkg? If so, can you build it using our output in MS build infra? And in this case, is it okay if we are ready first when Microsoft .NET release? (MS .NET release has a dependency on us.)

Can you please share a more concrete example of this scenario? I would like to understand this case better.

if we have a seperate build system, we need to publish nupkgs at the same time, at the same version id. How can we sync with? Is there any infra to trigger us? Or do you give us some permission to access MS build infra system?

For the .NET Core nuget package list above, everything that does not start with runtime. is known as Identity Package and these packages do not contain native binaries. They do contain, however, references to the various runtime.* packages that contain native binaries.

As long as the identity packages produced by us reference the runtime. packages produced for Tizen, all that will be required for you is to build the Tizen specific runtime. packages and upload them. We will continue to upload the Identity packages and thus, there should not be a conflict for sync.

For .NET Core SDK nuget package list, do they contain anything Tizen specific (e.g. Tizen specific native binaries that are produced in addition to what are produced for .NET Core)?

We have a special repository in Tizen, but this is merely a way to get the github code to tizen

How would you handle the case when there is a bug that requires fixing for Tizen, may or may not be fixed in .NET Core 2.0 servicing branches and you need to ship a servicing update for Tizen devices? Will you be making/porting fix to your special branch and ship the fix from there?

CC @weshaggard (for packaging in general) and @eerhardt and @livarcocc for CLI packages.

[gkhanna79]

@hqueue In general, it should be possible for us to reflect status of Tizen daily build of Core-Setup on Core-Setup main page.

[gkhanna79]

@hqueue @jyoungyun Any thoughts?

[jyoungyun]

@gkhanna79 Okay, as you said, we are considering running a separate release infra to upload nupkg for tizen. But there are a few things you need to check.

1. When we release tizen nupkg separately, you should refer to myget for tizen during development process and refer to nupkg with owner Samsung(or Tizen) at official release. Therefore, tizen myget should be added to NuGet.Config of each project(coreclr, corefx and core-setup).

2. In this case, we have two code repositories. One is to create nupkg, which is 100% identical to the .NET Core 2.0 servicing branches. Another repository is a branch for shipping to a Tizen device. This will most likely match the .NET Core 2.0 servicing branch, but as you said, we need to first update the patches here if we require fixing for Tizen and this pach will reflect to .NET Core 2.0 servicing branch too.

3. Is there a signing process for nupkg, native binary or managed dlls? If necessary, can we sign in our infra?

4. And can I know the build pipeline's build cycle? Should we also build nupkg with the same cycle?

Finally, it seems to take some time to build a separate release infra. I do not know if this will be finished until the 2.0 preview release(the mid of May). If it is not possible, how about you to create nupkg for tizen up to 2.0 preivew release and then upload in our infra? If not, please let me know if I can put a tizen release infra related code in the servicing branch even after branching out the .NET Core servicing branch. Our goal is to set up nupkgs and .NET Core for tizen to match the 2.0 official release schedule.

Many thanks :)

[lemmaa]

In this case, we have two code repositories. One is to create nupkg, which is 100% identical to the .NET Core 2.0 servicing branches. Another repository is a branch for shipping to a Tizen device. This will most likely match the .NET Core 2.0 servicing branch, but as you said, we need to first update the patches here if we require fixing for Tizen and this pach will reflect to .NET Core 2.0 servicing branch too.

Nevertheless, we hope that this situation will not happen. This second repository is only intended to serve as a gatekeeper for the different release cadence of .NET Core and Tizen, not to reflect different code. We will reflect upstream in all cases.

[gkhanna79]

you should refer to myget for tizen during development process

Are you referring to the feed to which you will upload the packages? If so, we could add reference to your feed or, for simplicity, could we consider having them uploaded to .NET Core feed. What do you think?

refer to nupkg with owner Samsung(or Tizen) at official release

@weshaggard Do Nuget.org feed's have owner-specific URIs? Or, can Tizen folks upload their runtime.* packages to nuget and anyone will be able to pull them down (including us). I would expect the latter to hold true but want to confirm with you.

In this case, we have two code repositories.

@jyoungyun I would have expected that the branch (in the repo) that you use to build the Tizen binaries would also produce the nuget packages that carry those binaries. Can you please help me understand why you need two repos? We do the same (branch building product also produces the nuget packages that carry the built binaries).

I am not aware of any nuget package signing we do. We sign our Windows binaries before they are packaged into nuget packages.

Should we also build nupkg with the same cycle?

Yes - as I mentioned above, this is what we do and I would suggest you consider doing the same (instead of having two repos or branches for doing so).

If it is not possible, how about you to create nupkg for tizen up to 2.0 preivew release and then upload in our infra?

Just so I understand this right:

1) are you suggesting to build the tizen runtime.* packages in our pipeline build for preview timeframe?

2) And by preview-timeframe you expect to have the changes at your end to build the runtime.* packages that you will be able to push to myget/nuget?

Thanks for driving the discussion @jyoungyun - I appreciate it :)

[jyoungyun]

@gkhanna79

could we consider having them uploaded to .NET Core feed. What do you think?

If you don't mind, we can use .NET Core feed too.

Can you please help me understand why you need two repos?

Oh, I should have explained more about our build infra, I'm sorry. :) We can not use network in our build infra. So we have to separate the repository for shipping to Tizen devices and the repository for uploading nupkgs.

This is a beside, you can access Tizen build system and you can also see the coreclr and corefx repository here. But as I said, we can not use network during build in our build infra so these repository need to keep an archive containing Tools and packages directory. And if the build must need nupkg like corefx, we also keep nupkgs, which I downloaded in advance. I would like to import core-setup into our system, but core-setup is not easy because almost part is related to the network.

Yes - as I mentioned above, this is what we do and I would suggest you consider doing the same (instead of having two repos or branches for doing so).

We only need to sync between the repository for uploading nupkg and your pipeline build infra. The repository for shipping to Tizen devices does not need to sync for build. We build this repository only when we have our requirements.

Now I'm building new infra for uploading nupkg, if this is not done by the end of April, then can you put tizen runtime.* packages in temporarily? If you work from the end of April, will it be uploaded before the May Preview release?

Have a nice weekend :)

[gkhanna79]

I think it should possible to have your infrastructure publish packages during build to .NET Core feed on myget for simplicity (CC @weshaggard for context).

Now I'm building new infra for uploading nupkg, if this is not done by the end of April, then can you put tizen runtime.* packages in temporarily

Thanks for describing your build infrastructure @jyoungyun. Does it mean that when you need to push to myget, it will be done by the second repo?

I think we can look into doing so if you are not able to get the infra for uploading Tizen runtime.* to myget by end April. However, lets keep in sync on the status next week to understand how this is going.

[jyoungyun]

@gkhanna79

Does it mean that when you need to push to myget, it will be done by the second repo?

First repository is for upload tizen runtime nupkgs
Second repository is onlly for shipping to Tizen device

And I'm building the First repository for uploading runtime.tizen.4.0.0-armel-* nupkg. Then, how can we sync btw MS buildpipeline and our infra? How often do you run buildpipeline(it means the job for uploading nupkgs to myget)?

And how can I pass the OfficialBuildId to build.sh? My result nupkgs are not the same BuildMinorVersion with your pipeline nupkgs.
My version : 2.0.0-preview1-25218-0
dotnet Myget version : preview1-25219-01

Oh, I have one more question.
Recently when I built corefx, the Microsoft.NETCore.Platforms nupkg was not generated in corefx, even if I built Linux x64. Do you know about it?

[gkhanna79]

@jyoungyun my point of "sync" was to check on how things are going :) Do you still feel you will be able to make end of April?

[jyoungyun]

@gkhanna79

Do you still feel you will be able to make end of April?

I'm trying now. :) Now I got it about Build Major number meaning. It means month and day. The problem is a minor version. Our build infra is running on Jenkins. What about use a specific branch for triggering builds at the same time? If a commit is merged into a specific branch, our infra can trigger build.

However, to build corefx or core-setup for the first time, nupkg for bootstrapping must be loaded first, but the Microsoft.NETCore.Platforms nupkg is not created. I think we do not need to build it in our infra because it does not have a runtime package, but I want to know where it is built.

[jyoungyun]

@gkhanna79 To make tizen runtime nupkgs is almost finished. So we need to talk about sync btw yours and ours buildpipeline. What about use a specific branch for triggering builds at the same time?

[gkhanna79]

Great to hear that @jyoungyun - Can you please elaborate on your question? I would expect that you should be able to able to get your runtime.* packages built on your own schedule and publish them to the same myget feed (dotnet-core) as us (I chatted with @weshaggard about this on Friday and he can help with it).

[ericstj]

I'm not sure if putting Tizen mappings in the Microsoft.NETCore.App runtime.json is the right point of hook-up. It seems like we're adding an unnecessary additional piece to these. Have you considered creating your own package with a runtime.json that just hooks up the tizen RID-specific packages? Runtime.json's can come from any package and NuGet merges them in. You could automatically reference a package of your own through targets the same way NETCore.App is referenced.

Doing this would let you own more of the things that make up your platform. That way if they need to change you wouldn't be dependent on us to make that change.

Additionally: wasn't Tizen supposed to be a different TFM completely? Why would it even be using the Microsoft.NETCore.App package which contains the reference assemblies for the netcoreapp TFM?

[jyoungyun]

@gkhanna79

I would expect that you should be able to able to get your runtime.* packages built on your own schedule and publish them to the same myget feed (dotnet-core) as us.

I think the packages which have a same name should be built from the same code. But if we have a different build cycle, the file name can be different and the result is not built from the same code.

And, to build corefx and core-setup, it should resolve the dependency of those modules. I mean if the CoreClrExpectedPrerelease indicates preview2-25226-02, tizen runtime pkg should be already uploaded the same version to myget. But if we do not sync a build cycle, there is no guarantee that tizen build will always be.

[jyoungyun]

@ericstj

I'm not sure if putting Tizen mappings in the Microsoft.NETCore.App runtime.json is the right point of hook-up.

Is there any source file that contains Tizen mappings for the Microsoft.NETCore.App? If you mean the Microsoft.Private.CoreFx.NETCoreApp, we are still considering about tizen tfm and netcoreapp tfm. Also we requires preview1 release to use tizen tfm. But we have to work on it before release, so we added some patch for tizen rid to Microsoft.Private.CoreFx.NETCoreApp. We have a plan to use tizen tfm in preview2 release. I will share it with you if there are any changes in this content.

/cc @lemmaa @hqueue @WonyoungChoi

[ericstj]

Is there any source file that contains Tizen mappings for the Microsoft.NETCore.App? If

Right now https://github.com/dotnet/core-setup/blob/6887ab556bc8302390782711dcdd75b75e769cf5/src/pkg/projects/netcoreappRIDs.props#L41-L43 is causing us to emit Tizen RIDs into the runtime.json that is part of the Microsoft.NETCore.App package. Same for all the host packages.

I'm ok with Microsoft.Private.CoreFx.NETCoreApp package referring to tizen RIDs. That package is private and only used for moving bits between the repositories. The Microsoft.NETCore.App package will ship publicly with 2.0 RTM and it could be problematic if that has version specific mappings for Tizen and you want to move those independently. Or pull them in independently of the reference assemblies that are part of the same package.

[gkhanna79]

We have a plan to use tizen tfm in preview2 release.

@jyoungyun @hqueue If you intend to go this route, it needs to be done by 5/10 (see https://github.com/dotnet/coreclr/issues/11248).

[gkhanna79]

Have you considered creating your own package with a runtime.json that just hooks up the tizen RID-specific packages?

@jyoungyun Did you get a chance to look into this approach that @ericstj suggested?

[jyoungyun]

@gkhanna79 We need to discuss how to sync btw our release infra and yours build pipeline. Now I'm building coreclr,corefx and core-setup six times a day, every four hours. But we have to trigger those release infra at the same time. Could you worry about this first? This should allow me to successfully upload tizen nupkgs to dotnet-core myget and build the relevant build infrastructure properly.

[gkhanna79]

@jyoungyun I was chatting with @ericstj and he pointed me to https://github.com/NuGet/NuGet.Client/pull/1083 that added the Tizen TFM to Nuget. Given this, it is not clear whether you are building your packages for Tizen TFM or the NETCoreApp2.0 TFM. Can you please comment on this? That is, are you building _runtime.tizen.4-armel.Samsung.Tizen.App_ package OR are you building _runtime.tizen.4-armel.Microsoft.NETCore.App_ package?

If you are going to be using Tizen TFM, then you can name your packages to the name of your choosing and we do not have to have references for Tizen in Microsoft.NETCore.App package since that corresponds to _netcoreapp2.0_ TFM and not a Tizen TFM.

But we have to trigger those release infra at the same time. Could you worry about this first?

What is your specific concern around this? Assuming you choose to use _netcoreapp2.0_ TFM, suggestion by @ericstj above still makes sense as it allows you to evolve independent of our build timing/schedule.

CC @terrajobst

[jyoungyun]

@gkhanna79

it is not clear whether you are building your packages for Tizen TFM or the NETCoreApp2.0 TFM.

We will use and support both TFMs, NETCoreApp2.0 TFM and Tizen TFM. The plan to support Tizen TFM is scheduled for a next preview release. But to support NETCoreApp2.0 TFM should be resolved in 1st preview release.

Even though the Tizen RID is described in netcoreappRIDs.props, I think I need to upload runtime.tizen.4.0.0-armel.Microsoft.NETCore.App.2.0.0-preview1-*.nupkg. Am I wrong? If coreclr, corefx and core-setup upload nupkgs for tizen to dotnet-core myget, it will be restored without problems for tizen. But currently those runtime nupkgs are not uploading automatically due to build sync issue.

Now, the important problem is that coreclr, corefx and core-setup should be built at the same time as you build. I think nupkg for the same build number should be built from the same code. If you have uploaded 25304-01 nupkg, I should build 25304-01 runtime nupkg for tizen in the same code. Currently I am doing a random build because I do not know when you build it. Also, since your minor number policy is not public, our build system will break if you randomly build it with a minor number 52 and put in dependencies on that package.

Assuming you choose to use netcoreapp2.0 TFM, suggestion by @ericstj above still makes sense as it allows you to evolve independent of our build timing/schedule.

I do not understand that despite our use of netcoreapp2.0 we can evolve independently of your builds. Could you explain more?

[gkhanna79]

I think I need to upload runtime.tizen.4.0.0-armel.Microsoft.NETCore.App.2.0.0-preview1-*.nupkg

If, for the first preview release you are going to target netcoreapp2.0 TFM, then this is necessary and you will need to upload the packages.

If you have uploaded 25304-01 nupkg, I should build 25304-01 runtime nupkg for tizen in the same code.

@weshaggard Is there a property that @jyoungyun can you to specify the build number to be used when they do a build, as opposed to trying to sync with out build?

@jyoungyun assuming there is a way for you to specify a build number, will you be able to determine the CoreCLR/CoreFX/Core-Setup package build number versions and have your build use that?

[weshaggard]

@weshaggard Is there a property that @jyoungyun can you to specify the build number to be used when they do a build, as opposed to trying to sync with out build?

Assuming these are using the BuildTools versions now they can be overridden by setting these properties https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/versioning.targets#L11.

[jyoungyun]

@gkhanna79 @weshaggard As I know, the -OfficialBuildId is to specify build number, isn't it? I already use the -OfficialBuildId option to build coreclr and corefx by setting the same build number. So I can build those module with a specific build number. But what I worried about is the build trigger point. I think if your build is building with a 20170510-01 as -OfficialBuildId, you need to trigger to us at that point. Does the output of the same build id need not be built in the same code?

[gkhanna79]

As I know, the -OfficialBuildId is to specify build number, isn't it?

I don't think that is correct as OfficialBuildId is different from the build number that is appended in 2.0.0-preview2-<build number>-<build leg number>. Please see https://github.com/dotnet/core-setup/issues/1566#issuecomment-299953723 that explains which version number to use.

But what I worried about is the build trigger point.

To confirm, you would like to ensure that your build triggers using the same SHA commit as our build did, and not really about triggering at the same time, right?

[gkhanna79]

[eerhardt]

[gkhanna79]

[weshaggard]

[gkhanna79]

[weshaggard]

[gkhanna79]

[weshaggard]

[joperezr]

[joperezr]

[gkhanna79]

[joperezr]

[jyoungyun]

[gkhanna79]

[jyoungyun]

[weshaggard]

[jyoungyun]

[gkhanna79]

[joperezr]

[eerhardt]

[joperezr]

[weshaggard]

[joperezr]

[jyoungyun]

[eerhardt]

[gkhanna79]

[jyoungyun]

[jyoungyun]

[gkhanna79]

[eerhardt]

[dagood]

[gkhanna79]

[jyoungyun]

[gkhanna79]

[jyoungyun]

[dagood]

[jyoungyun]

[eerhardt]

[gkhanna79]

[gkhanna79]

[jyoungyun]

[gkhanna79]

[eerhardt]

[jyoungyun]