Jenkins to MySQL: How to Move Your Data
Move Jenkins build history into MySQL with Airbyte. Why per-job retention sets your sync schedule, what the two streams cover, and defining metrics in views.
Moving Jenkins into MySQL gives build history a permanent home and makes it queryable with SQL. Jenkins keeps only as much as its retention policy allows, and answering how delivery has changed over two years needs data the controller discarded months ago.
This guide covers the managed path with Airbyte. The scope is narrow and the schedule matters more than usual, because anything Jenkins discards before a sync reads it is gone from both systems permanently.
Jenkins to MySQL at a glance:
Why move data from Jenkins to MySQL?
Two situations account for most of these pipelines.
The first is engineering metrics over a long window. Build frequency, failure rates and duration trends need history that outlives the controller's retention, and MySQL is a perfectly good home for a dataset measured in thousands of rows per week.
The second is joining build data to what already lives in that database, such as service ownership, incidents or deployment records. If you are reporting across a very large estate over many years, a warehouse is the better destination, though few Jenkins installations produce enough to warrant it.
What do you need before you start?
Short list, and the last item is the one that determines your schedule:
A Jenkins user and API token. Generated by logging into Jenkins and visiting the configure page for the account. Use a service account scoped to the jobs you need, since the token runs as that account and inherits what it can see. The Jenkins source documentation covers the fields.
A reachable Jenkins server. Jenkins is almost always self-hosted and frequently sits inside a private network, so a failed connection test is usually networking rather than credentials. Establish that path first.
A MySQL user with write access. On the target schema, ideally one dedicated to synced data. Airbyte adds its own metadata columns, so plan to expose views to anything reading this rather than the raw tables.
Your build retention settings. Find out how many builds your jobs keep before discarding them. That number sets how often this pipeline must run, and it is configured per job rather than globally.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the MySQL side before you begin.
How do you build a Jenkins to MySQL pipeline in Airbyte?
Step 1: Check the retention policy on your busiest jobs
Look at the discard old builds configuration on the jobs you most want to measure. That number is the outer bound on how long you can go between syncs, and it is usually tightest on exactly those jobs, for reasons covered below.
Step 2: Configure the Jenkins source
Click Sources in the left navigation, then New Source, and select Jenkins, following adding a source. Supply the server URL, username and API token. Airbyte tests the connection immediately, and if it fails check network reachability before credentials.
Step 3: Configure the MySQL destination
Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. Volume is not a concern on this pipeline, so the constraint is retention on the source rather than anything about the destination.
Step 4: Create the connection and sync often
Click Connections, then New connection, and select both streams with a sync mode each. Builds supports incremental, so use it. Set the frequency against your Jenkins discard policy rather than how fresh anyone wants a dashboard, which on a busy controller may mean several times a day.
That is comfortable to do, because the connector should not run into Jenkins API limitations under normal usage. Your constraint is what the controller still holds rather than how fast you may ask for it.
Why does retention set your schedule?
Because Jenkins discards old builds so the controller does not fill its disk, and once a build is discarded it is gone from the source. A sync running less often than the discard policy will miss builds permanently, and nothing about the pipeline will tell you.
The awkward part is which jobs this affects. Retention is configured per job and is usually tightest on the pipeline running on every commit, because that is the one generating the most builds and consuming the most disk. So your busiest and most interesting job is the one most likely to lose data between syncs.
Set the frequency against the shortest retention among the jobs you care about, and alert on sync failures rather than letting a broken connection sit over a holiday. On most pipelines a pause produces staleness you catch up on; here it produces a permanent hole.
What can two streams actually tell you?
More than it sounds, provided you know what is absent. Build records carry status, timestamps and which job produced them, which is enough for failure rates, duration trends and build frequency by job or team once you join the two streams.
What is not here is console output, test reports and artefacts. So you can see that a build failed and not why, which means this dataset answers questions about patterns rather than incidents. Anyone wanting to investigate a specific failure goes to Jenkins, and your tables should link them there.
Take the jobs stream even though it changes rarely, because build records reference jobs by identifier and without it your reports show numbers against something no human recognises. Then define duration and failure rate once in a view, so two teams do not compute them differently from the same tables.
Frequently asked questions
Which streams does the Jenkins connector provide?
Builds, which supports incremental sync, and jobs. Console logs, test reports and artefacts are not included.
Why is my build history incomplete?
Jenkins discarded builds before a sync read them. Retention is set per job and is usually tightest on your busiest pipeline, so sync more often than your shortest discard policy.
Can I find out why a build failed?
Not from this dataset. Console output and test reports are outside the connector's scope, so store the build record and link to Jenkins for the detail.
Is MySQL big enough for this?
Comfortably. Build records are modest even on a busy controller, so the volume guidance for relational destinations is not a concern here.
Can I do this without writing code?
The Airbyte setup is entirely UI-driven. You will want SQL views joining builds to jobs and defining your duration and failure measures once.
Get your Jenkins data into MySQL
Check retention on your busiest jobs and sync more often than they discard, because a gap here is permanent rather than something you catch up on. Take the jobs stream so identifiers resolve, define your measures once in a view, and alert on failures.
Airbyte's connector catalog includes 600+ pre-built connectors, so build data can sit beside incident and delivery sources. For the same source in another relational database, see Jenkins to PostgreSQL, and for repository activity alongside it, GitHub to MySQL.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.