I’m excited for animations to be supported! Uploading animations is a current bottleneck in my plugin; the best I can do now is prompt plugin:SaveSelectedToRoblox(). Manually naming an animation, specifying the group, and setting the AssetId is slow, so being able to do this programmatically would help speed up my workflow. This is awesome, thanks!
1 Like
Is this what the CI/CD asset API is supposed to be?
No worries. I am speaking purely from a development asset generation standpoint - i.e. thumbnails in UI. This API is not suitable for that as I need to preserve the background transparency or I will have tons of downloading and error prone postprocessing to do.
1 Like
Would it be possible to open up the Open Cloud endpoint for uploading mesh and image assets directly? With this new AssetService API, it is possible to automatically upload mesh and image assets from an external program, but only through the context of Open Cloud Luau Tasks. Is there a reason why this extra step needs to be taken, and I can’t just directly upload the assets without going through Luau cloud execution? Since Luau tasks are cloud-based, it’s only adding extra latency to the development pipeline.
1 Like
Sorry it took a while to reply, on the surface this sounds like a really cool capability for plugin authors, and definitely something we would like to enable.
There are serious questions about safety and consistency of the Studio experience, so we will probably need to invest in better per-plugin permissions before we can consider building such an API.
Thankfully, part of taking this API (CreateAssetAsync) out of beta, does involve improved plugin permission investments, so we may be able to re-use what we are building for asset upload to deliver a clipboard API.
No promises, but if we can do it safely, I think we should 
2 Likes
This is amazing, and thanks a lot for this update.
Will you introduce more supported asset types in the future? If so what would those be?
1 Like
Finally, amazing feature!
My plugin is now usable 
Still praying for exceptions in the Editable Image creation permission check
3 Likes
This is pretty awesome, I’ve been able to use this successfully to publish my Luau Language Server Companion plugin from GitHub to Roblox seamlessly! It was the last missing piece for my fully automated release workflow, thank you so much!
Example implementation: Create workflows to publish Companion plugin by JohnnyMorganz · Pull Request #858 · JohnnyMorganz/luau-lsp · GitHub (with a workflow run)
What is the reason behind these being necessary to provide in an OpenCloud Luau task context?
If I looked at an example OpenCloud response, it already has my user prepopulated, so it seems that OpenCloud already knows what user is logged in here:
{
createTime = "2024-12-08T14:00:43.297Z",
error = {
code = "SCRIPT_ERROR",
message = "No logged in user, CreatorId must be provided as it can not be inferred",
},
path = "...",
script = "",
state = "FAILED",
updateTime = "2024-12-08T14:00:46.780Z",
user = "68136726", -- this is me!!
}
1 Like
yeah, that is what i have been wondering too, why do we have to use Luau Execution Tasks instead of the Open Cloud API directly with Http requests?
Yes, we also wish that we could either auto-populate those fields (like in studio), or at-least, give you access to them via some context in the RCC.
I am confident this is something we will be able to solve in the future, but with Luau tasks being a brand new concept, there are some technical complexities between how auth is handled in RCC and how OpenCloud auth works that makes this impossible today; we felt this was useful enough to ship with this annoyance today while we do the long-term work to make those systems fully compatible.
A few details: we had to build a temporary “bridging” solution to allow RCC-authed requests to be "converted’ back into OpenCloud authed requests specifically for Luau tasks. I can’t go into too many details, but the TLDR is that, today, RCC has no knowledge of your OC credentials. We have to do a bit of magic in this “bridge” to ensure the OC credential has the right scopes/permissions for what RCC is trying to do, and then swap out the RCC auth for OC auth.
This will improve as we continue to invest in Luau tasks, apologies for the current inconvenience
1 Like
Yes, we are definitely looking at Animation and KeyframeSequence next, another one that was brought up is the ability to create Decal and MeshPart from EditableImage/EditableMesh respectively, we will study the value of this use-case as well.
Are there any specific asset types you have in mind? It is incredibly helpful if you can share workflows you would like this API to support that is cannot today!
1 Like
That is great! This will open up so many possibilities
The one type of asset I had in mind were Accessories. From what I understand, this could be used to achieve bulk uploading, which could save some valuable time for many people. (correct me if i am wrong though, please) But this might be more complicated than it sounds to introduce as it has to pass validation first.
Even if its not possible, this is definitely a great great feature! Thanks for the amazing work. 
1 Like
I agree, automating accessory upload would be a very powerful workflow, as you point out, accessories have much more involved validation and error states. I will discuss this with the team that owns that system.
It may pan out that a separate API for accessories is necessary, but, if your accessory is composed of meshes/images you may still want to create those form Lua first with CreateAssetAsync so they may work together, I will do some research and get back to you!
1 Like