Azure Logic Apps
Azure Logic Apps functionality has been a part of the Arcus Scripting library for a long time. The recent changes only expand the usability further to bring real added value to projects working with Logic Apps.
Resubmit failed instances on an Azure Logic App
One of the hurdles with managing failed Azure Logic Apps instances is that you have to manually resubmit each instance individually in the Azure Portal. There is no ‘batch’ functionality available for this kind of operation. That is why the new v1.0 release has a new command in the Arcus.Scripting.LogicApps PowerShell module that lets you interact with the Logic App in a high-level way. Instead of specifying each failed instance separately, it uses date filtering to identify many failed instances in a given time frame.
🔗 For more information on this particular command and other Logic Apps-related commands in this module, see our feature documentation.
Cancel running instances on an Azure Logic App
As with failed Logic Apps instances, there is no ‘batch’ functionality to cancel running instances on an Azure Logic App in the Azure Portal. This is particularly a problem when the instances were accidentally triggered by a big load. With a combination of several Azure PowerShell commands, you can mimic this functionality, but this is not maintainable or easy to transfer to other projects that require the same or similar functionality. Arcus Scripting v1.0 also includes a ‘batch’ version of canceling many running Azure Logic Apps instances in one go.
🚩 It is important to note that this functionality is externally requested by a contributor. It is yet another great example of the usability of the Arcus Scripting library. It is fully grown out of the challenges and struggles of interacting with Azure-related resources using PowerShell. This extra layer makes this interaction more comfortable and logical.
🔗 For more information on this particular command and other Logic Apps-related commands in this module, see our feature documentation.
Azure DevOps
Interacting with DevOps functionality requires constant research for the correct syntax and possibilities. Luckily, with Arcus Scripting we have bundled commonly used functionality in the Arcus.Scripting.DevOps module which the v1.0 release enhances even further.
Set a variable as secret
Setting a secret in Azure DevOps dynamically at runtime requires you to write a specially designed host message. Because of this fragile way of working, we already had a command that was able to do this for you. This release now adds the option to dynamically write a variable as a secret. This means that it is not publicly logged in the build output, so is handled with more care.
🔗 For more information on this particular command and other DevOps-related commands in this module, see our feature documentation.
Set a custom retention period
We were already able to programmatically retain an Azure DevOps build indefinitely. In some scenarios, however, indefinite is too long, especially if you have to delete them manually. The new v1.0 release will let you pass in the number of days such a build should be saved, making the command more flexible for numerous scenarios.
💡 The variables $(System.TeamProjectId) and $(Build.BuildId) are predefined Azure DevOps variables. Information on them can be found here.
Conclusion
We have released Arcus Scripting v1.0! 🎉
Besides some great new and enhanced functionality, this new major release has a big role to play. We are confident that the Arcus Scripting library is mature enough to move to an official v1.0 release. It has been used across several projects, and has received many enhancement and feature requests, which makes it mature enough for us to decide to take this milestone of a step.
Have a look at our release notes and official documentation for more information on this new release.
If you have any questions, remarks, comments, or just want to discuss something with us; feel free to contact the Arcus team at Codit.
Thanks for reading!
The Arcus team
Subscribe to our RSS feed