But don't just leave them at that, do work on eliminating their need. Sisyphean task but necessary nonetheless.
But this isn’t good, we have Airflow and that’s where these things should be. Their stay inside Jenkins is technical debt, but at least is much better than not having it automated. The advantage is that you made an ad-hoc process less unstructured, you can add post-failure alarms, you don’t have to worry about long running scripts being interrupted by shabby notebooks, you don’t need to spread production credentials to every developer and so on.
We introduce many things that way. First it's just a few commands that do something useful. Then included in the repo. Then tweak. Next thing you know there's an endpoint with that functionality because it's useful and frequently needed.
…otherwise we just throw everything into a scripts directory. Keep it flat until it feels messy, then start organizing. All documentation must live with the code, otherwise it gets out of date too easily.
Oherwise, I just use git like others said but that can be suboptimal for non technical or semi technical users.
Not the greatest solution but it did ensure they never got lost.
Most scripts were never re-used, so it was not a problem all that often.