-
Notifications
You must be signed in to change notification settings - Fork 124
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
Comments
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. 🫠 So, well... |
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. |
Now, we have symbols from AppSource Apps and Microsoft Apps - we need to go the next step.
The text was updated successfully, but these errors were encountered: