Skip to content
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

Runtime packages - finalize #1332

Open
3 tasks
freddydk opened this issue Nov 21, 2024 · 3 comments
Open
3 tasks

Runtime packages - finalize #1332

freddydk opened this issue Nov 21, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@freddydk
Copy link
Contributor

Now, we have symbols from AppSource Apps and Microsoft Apps - we need to go the next step.

  • How does partners generate and publish runtime packages to NuGet easily
  • Document how to share NuGet packages with other partners
  • Document how to trust partner NuGet packages (using PATs, OAuth and federated credentials)
@freddydk freddydk self-assigned this Nov 21, 2024
@freddydk freddydk converted this from a draft issue Nov 21, 2024
@freddydk freddydk added the enhancement New feature or request label Nov 21, 2024
@sschuh-mumdat
Copy link

That is, status today, exactly one of the features that is still stopping us from switching.

Of course, the ideal solution would be to create the runtime packages without the presence of a container. 🫠
I know...Another story...Not really in your own hands...

So, well...
At this point I would like to say a big thank you for your work. Simply great.♥️

@jonaswre
Copy link
Contributor

We have a flow that’s working, more or less.

I’ve updated the repo that @freddydk created for Runtime generation. I reworked it so the Runtime generation can now be triggered just by specifying the repo name.

The action grabs the latest release from the specified repo and resolves all dependencies using the internal NuGet feed. Once the runtimes are generated, the resulting NuGet package is uploaded to a second organization. From there, we invite our partner and grant them access to the runtimes.

This setup has a few drawbacks. First, everyone you invite can see each other, which isn’t ideal. Second, the UI is clunky—you have to use PowerShell, and there’s no GUI. Third, it’s horribly inefficient. We’re building some of our apps from versions 21.0 to 25.1 in every language for every release. That’s a ton of wasted compute cycles. But as long as Microsoft is footing the bill, I’m not too concerned. If it ever gets too expensive for them, they can deal with fixing the runtime situation themselves.

Another quirk: you need a separate BC Runtime repo for every App repo. If you don’t, builds from different apps might cancel each other out. That said, since Microsoft is paying, the best strategy might be to create a new organization for every App repo. This would let you parallelize runtime creation even further, though I’m not sure how many organizations you can actually create before hitting a limit.

Honestly, it’s a waste of time trying to work with this runtime mess. Microsoft needs to stop chasing AI hype and focus on building a proper framework—one that allows partners to spend their time delivering value to customers instead of dealing with these problems.

@jonaswre
Copy link
Contributor

jonaswre commented Nov 25, 2024

Image
Thats 1/3 of our included runner minutes if we had to pay it. Just to get a few runtimes.

@freddydk freddydk changed the title Runtime packages Runtime packages - end-game Dec 16, 2024
@freddydk freddydk changed the title Runtime packages - end-game Runtime packages - finalize Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🧹 Grooming
Development

No branches or pull requests

3 participants