Build NuGet and CloudSmith Packages (OCC-29)

[agriffard]

Will you create a dev branch at some point?

Then, is it possible to setup a CI (Travis, AppVeyor) in order to build the packages?

It would be great if devpackages could be uploaded to a MyGet feed and master to NuGet, as it is done in OC.

[bleroy]

Sure is possible.

[bleroy]

I'd add to this configuring GitHub actions to build, package and test, rather than an external CI, if that's sufficient for our needs.

[barthamark]

I believe this is complete. Is there anything else missing from here @bleroy @agriffard ?

[bleroy]

As far as I can tell, the CI workflow doesn't upload packages to MyGet and NuGet as requested by @agriffard .

[Skrypt]

Should we push to the same Cloudsmith account as Orchard Core or we should ask you Bertrand to create a separate account for MyGet, Nuget, and CloudSmith?

I got stuck while reorganizing the projects a while ago because the project is built as a single shared assembly while I think some projects could/should be abstractions and used as Nuget packages.

[bleroy]

I'm puzzled: the project is not built as a single assembly.

Also, since I'm no longer the main maintainer of the project, it wouldn't make sense for me to open the accounts. The project is under the Orchard GitHub org, it seems like we should do the same thing and use the same accounts as the main project.

[Skrypt]

You are right It is not a single assembly. We need to ask @sebastienros what he thinks about it.

[Skrypt]

Here is my confusion.

I created an OrchardCore.Commerce.Targets module so that I can reference it simply from my main web project. This way, it becomes a single required referenced assembly. Though, I did this to replicate also the Orchard Core project folder structure so that I can reuse the same Github workflows and VS Code launcher/tasks.

[sarahelsaig]

This can utilize our reusable GitHub workflow for publishing to a NuGet feed. I don't think it's necessary to have a separate dev branch, pushing to main could trigger a publish for CloudSmith/MyGet and creating a release could trigger a publish for NuGet. That would be cleaner and I think we have all the pieces to make it happen.

@sebastienros what do you think, should it be under the Orchard Core CloudSmith account as Jasmin suggested?

[Piedone]

We can publish preview packages, i.e. packages after all main commits to Cloudsmith, under the OrchardCore account, and release packages to NuGet, under the Orchard account. I.e. the same as we do with OC.

[sarahelsaig]

@sebastienros could you please update the two secrets here? (CLOUDSMITH_API_KEY and NUGET_API_KEY; I have added the variables with only placeholder values.) Then we can start with this issue asap. Thanks.

[Piedone]

Before the first NuGet release, we should decide on the names of AddressDataType and MoneyDataType. I recommend just prefixing them with OrchardCore.Commerce..

[sarahelsaig]

I agree. Even if they are meant to be generic, they will evolve alongside OCC so they should be together. Anyone against this namespace change, please chime in.

[sarahelsaig]

@sebastienros could you please update the two secrets here? (CLOUDSMITH_API_KEY and NUGET_API_KEY; I have added the variables with only placeholder values.) Then we can start with this issue asap. Thanks.

up

[Piedone]

Hmm, the (or some) keys are there, actually!

So Sebastien swooped in but forgot to tell?

(Before you ask, I have access to this settings page but not to the NuGet account, hence why I didn't do it in the first place.)

[Piedone]

Ah no, now I notice that Dávid you added placeholders.

[sarahelsaig]

Yup, these are just the empty variables I've set up, waiting for the values to be updated. (you can see that the "days ago" is the same as my previous comment)

[Piedone]

I remembered I actually have access to the Cloudsmith repo! So created and configured one: https://cloudsmith.io/~orchardcore/repos/commerce/packages/

However, to provide push access to it, a user's API key is needed. You can only use a user's single, personal API key to publish packages. The recommended way to do this is by creating a bot account just for this. I'd do that, but I need to store the credentials somewhere. Isn't there an Orchard LastPass, @sebastienros?

[sarahelsaig]

The preview repo seems to be using Sébastien's personal account so a technical user probably wasn't considered. Can't we create a dedicated account using a Lombiq email address, at least for now? You wouldn't have to store the creds, since it won't be used for anything else. Then Sébastien & co can replace it with something else later if they want to.

[sarahelsaig]

btw I've already made the namespace changes and created the workflows in a branch. Didn't have the opportunity to test them in lieu of the API keys, but the NuGet workflow should be perfect as it's exactly the same we use to publish Lombiq's open source projects. The CloudSmith workflow required a non-trivial improvement in the parent action, because that would trigger on every main merge instead of a tag, but I'm optimistic and eager to test it.

[Piedone]

I've added Lombiq Bot to the Bots group (https://cloudsmith.io/orgs/orchardcore/teams/bots/members/) and configured the API key under Secrets.

[sarahelsaig]

Thanks. It works for CloudSmith now.

However for now I could only test it by pushing a tag. (Looks like on.publish.branches = ["main"] condition can only be triggered from the main branch? If so, that's perfectly logical. OC is doing the same anyway so it should be fine)

I'm still waiting for a NuGet key, then this can be reviewed.

[Piedone]

Yep, the branch trigger will only work if the workflow exists on that branch.

[sebastienros]

NUGET_API_KEY updated with same key as in OC

[sarahelsaig]

Thanks Sébastien, it works. https://www.nuget.org/packages/OrchardCore.Commerce