Hi!
So my news are sort of mixed. First, callbacks were considered them, had them in alpha, and then removed them to await further feedback, and here you are with further feedback . We also considered and spiked out a full easy-to-use public-facing editor deployment API, but since we had the CLI, we opted to have a small API footprint instead…
Second, while we don’t have exactly UI bound callback system, we do have the API services register publicaly exposed, and this can be used for automation.
You have a few alternatives
- Call the deployment code yourself (its public)
- Listen to a change of status
- Implement your own provider
- Set up automation with the CLI which supports deploy
If you reference “Unity.Services.DeploymentApi” in your assembly, you could do this
- Create your own automation (will require your own button)
using Unity.Services.DeploymentApi.Editor;
// ... stuff
// run my SO -> item code
var cc = Deployments.Instance.DeploymentProviders.First(s => s.Service == "Cloud Code"); // you may have to disambiguate between C# and JS here :-(
var item = cc.DeploymentItems.First(d => d.Name == "MyModule.ccmr");
await cc.DeployCommand.ExecuteAsync(new IDeploymentItem[] { item });
// run my copying code
- Listen on the item for its change of status (will work with our UI, but only after)
using Unity.Services.DeploymentApi.Editor;
// ... stuff
// run my SO -> item code
var cc = Deployments.Instance.DeploymentProviders.First(s => s.Service == "Cloud Code");
var item = cc.DeploymentItems.First(d => d.Name == "MyModule.ccmr");
item.PropertyChanged += (sender,
e) =>
{
if (e.PropertyName == nameof(IDeploymentItem.Status)
&& ((IDeploymentItem)sender).Status.MessageSeverity == SeverityLevel.Success)
{
//deployment is done
}
};
// run my copying code
- You can implement your own provider that wraps a different provider
(I wont go into too much detail about that one, unless you're interested)
- Use the CLI
For more longterm automation integrated with CI, consider this option. Let me know if you want more details
Now, for your first use-case, that seems like something we should be supporting by default (generating SO from inventory items or vice-versa), and something we’ve had in consideration for other services (analytics and CloudCode).
For your second one, I have a better recommendation… Keep your code in the editor and use the csproj to reference that assembly.
<ItemGroup>
<!-- relative path here depends on where your csproj is -->
<Compile Include="../Assets/DTOs/**/*.cs" />
</ItemGroup>
Now, I know that doesnt remove the need for callbacks, so if you have any ideas on what they’d be implemented on, I’m all ears, we’ll take it into account.
As a simple extension of the Deployment API?
As a binding you put on a deployment definition? (we thought of keeping callbacks scoped to a deployment definition)
Thanks, and sorry for the delay, I need to update my forum watching setup
Cheers!
Gab