I would caution against trusting your build process definition to hold up to time. It's definitely better than nothing.
Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).
It may not run to completion in the future, that’s true. However, if it’s something as simple as a shell script or a shell command list, it’s at least relatively transparent.
Unlike, say, tasks on Azure DevOps. Not a fan of those.
Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).