Scripts vs tasks in workflows

I recently read this article Bit rot is killing my pipelines by Richard Fennell (t | b) and this reminded me of a conversation we had in my time at Black Marble.

Essentially I had a bit of an interesting requirement to not be unable to build, test and locally release my scripts, modules, websites & applications if there was an issue with any of my hosted services. Now in many cases this is not so much of an issue any more, however I like to understand the moving pieces, especially if I decide I want to swap out any service that I am using. Something that I’ve done plenty of times with the likes of websites like this blog.

However, this wasn’t the only reason too. At the time I was regularly travelling and needed to be able to develop when disconnected or poorly connected. I also found that waiting for a remote build agent to be available and the build and then deploy tasks to run was far too time consuming if there were lots of changes happening in a small space of time.

This is especially more so problematic if you are doing infrastructure deployment testing, like with a large Azure or On-Premises deployment.

So I had mentioned to Richard & others that I was getting frustrated with ageing & non-updated tasks, but also in some areas, tasks that seemingly were getting updated and breaking their functionality due to their underlying platform of choice. A prime example of this is platforms deprecating and removing support for versions of Node, which many tasks are now being built on.

Personally, with PowerShell being available wherever I need it, I am going to write PowerShell scripts that are portable and work in local deployments as well as those on hosted agents, especially as this allows me to switch platforms (even to a custom one of my own) with very little effort if that is what I feel makes sense.

But this comes with the trade off of needing some additional maintained, that sometimes is better put into using the tasks available to us, so this is a case of your mileage may vary, but generally I think this is more supportable longer term than task reliance.

Make your own mind up about using tasks, as I found out recently in PR for the PowerShell Repo that some tasks can be opinionated in what they test against, and finding out which task is the actual one running that specific test was a rabbit-hole and a half to get into, for very little gain as I couldn’t in the end get the result I wanted so decided that experiment was concluded and that I wasn’t gonna waste any more time on it.

Also in this I recently tried updating my workflow for publishing posts, and this broke due to tasks changing their functionality, which forced me to revert to the working version. I think at some point I am very likely going to script this, again to enable me to move to other platforms if I choose to do so, including self-hosted ones.

I hope you enjoyed this post & are have a good day!