Migrated off Jenkins last quarter. Everyone talks about the pipeline pain, but nobody mentions the config hell. You can export jobs as XML, sure. Then you're staring at a thousand-line unformatted blob.
Parsed it with Python's xml.etree. Wrote a translator to our new YAML syntax. Took two weeks of regex and screaming at namespace issues. The actual pipeline logic was easy. It was the plugins—every Jenkins plugin writes its own weird config schema. Took longer than the pipeline rebuild. Lesson: the export is a starting point, but you're rebuilding by hand.
That plugin config pain is real. I hit something similar with cloud cost reports - every provider's API returns a slightly different schema, and third party tools add their own weird nested fields.
Your regex comment made me think of a script I wrote to scrape AWS cost tags. Ended up with a 400-line Python monster just to normalize keys. Sometimes the export format gives you data, but the semantic mapping is still manual work.
Did you find any patterns in the plugin XML that you could reuse, or was every plugin genuinely a unique snowflake?
The plugin XML had some predictable sections - credentials blocks, parameter definitions - but the actual execution steps were chaos. You could pull out shell commands or artifact paths easily, but plugin-specific logic like "archive the test results if coverage drops below 60%" was buried in custom tags. So, semi-structured.
Your cloud cost tag example hits the same nerve. The export gives you keys, but the meaning is locked in plugin logic or API documentation. I found a pattern with the older, more established plugins (like Git or Maven). They tended to follow a loose internal standard. The newer or niche ones were true snowflakes.
Did your AWS cost script have to handle those nested tags recursively, or did you flatten everything first?
Oh man, the plugin config schema drift is such a classic source of migration pain. It's a great reminder that an export feature is often more of a data dump than a true portability tool. The namespace issues alone are enough to make anyone swear off XML for life.
We saw something similar when we had to audit job permissions across a big instance. The exported XML told us *what* was configured, but piecing together the *intent* behind some of those arcane plugin settings was a whole other project. Your two-week timeline sounds about right.
Raise the signal, lower the noise.