This lesson comes at things from a different angle to the previous ones, and it is worth saying so up front: you are not going to choose Travis CI for a new project. What is very likely is that you will run into it — in an internal repository nobody has touched since 2019, in an open source dependency you want to contribute to, in the migration you get handed when you join a team — and that you will have to understand what that thirty-line .travis.yml does and translate it. And there is a second reason to devote a whole lesson to it: Travis invented a good part of what this course takes for granted. The CI file versioned alongside the code, the language version matrix, free unlimited CI for open source and the green badge in the README are all its doing; GitHub Actions and GitLab CI inherit its central idea. And then what happened, happened, which is the most instructive part: a change of ownership, a change of business model, a mass migration to another tool and a security incident that left a very hard lesson about entrusting secrets to a third party. We are going to look at what it contributed, how its fixed-phase model works, the Reservalia pipeline forced to fit inside it, what happened, and above all how to migrate a .travis.yml to whatever you use today.

1. What Travis contributed and why it matters
2. The fixed-phase model
3. A basic .travis.yml and the version matrix
4. The Reservalia pipeline forced to fit
5. Stages, caches and encrypted secrets
6. What happened: ownership, business model and exodus
7. The 2021 incident and the lesson about secrets
8. Migrating a .travis.yml: equivalence table
9. A complete migration, step by step
10. The portability lesson
11. When Travis still makes sense
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

Travis CI appeared in 2011, when normal CI meant a Jenkins installation somebody maintained and where configuring a project meant asking an administrator for a job and filling in a form (06-01). Travis proposed something else: a file in your repository and that is it.

With those four lines, every push triggered a build, on two versions of Node, on a clean machine, without having asked anybody's permission or installed anything. Four specific innovations, all invisible today because they are the standard:

The cultural effect was enormous: for years, the green Travis badge in the README was the sign that an open source project was serious. Thousands of projects adopted automated testing because the cost of entry dropped to a single file. It is hard to overstate how much of today's CI culture comes from there.

That is the reason to study Travis even if you never use it: understanding the .travis.yml is understanding the mental model everything else derives from, including its limitations, which is what pushed its successors to design themselves differently.

Here is the structural difference from everything we have seen. Jenkins, GitLab, CircleCI and GitHub Actions let you define the stages and their dependencies. Travis does not: it has a predefined phase lifecycle and you fill in the ones you need.

What you gain and what you lose with fixed phases:

You gain brutal simplicity. There is no need to decide the pipeline's structure: the structure is already there and you fill in the gaps. For 90% of the open source projects of 2013 — install, test, report — it was exactly what was needed, and the file fitted on one screen. It also makes files comparable across projects: you know where to look.

You lose everything a real delivery pipeline needs:

• There is no graph. You cannot say "publish depends on quality and on test but not on the documentation". The order is what it is.
• There are no jobs with arbitrary dependencies. stages arrived late and they are sequential, not a DAG.
• There is no parallelisation within a job. The sharding of 02-04 has to be simulated with matrix entries and environment variables.
• Passing artifacts between jobs does not exist natively. Each matrix job is independent and starts clean; to pass dist/ from one job to another you have to upload it to S3 or some other store yourself. This is the most severe limit: the single-artifact promotion of 02-06 cannot be expressed in the model.
• Conditionality is poor. if: exists, but there is nothing like rules or rich expressions.

The conclusion, which is what makes this lesson didactic: the fixed-phase model is excellent for CI and structurally insufficient for CD. And that explains why the successors — GitLab with stages and later needs, CircleCI with workflows from the start, GitHub Actions with needs — put the graph at the centre. It was not fashion: it was the correction of a specific limitation.

1. dist chooses the base image (trusty, xenial, bionic, focal, jammy). It is the closest thing to runs-on, and a classic source of broken builds: projects pinned to dist: trusty that stopped working when that image was retired.
2. The implicit matrix is the idea that got copied the most: listing values for the language key generates one job per value.
3. services enables services already installed in the VM. It is different from GitLab's or GitHub's services, which start containers: here you do not pick the version precisely, you run whatever the image ships. Less control, less ceremony.
4. cache: npm: true is caching by convention: the provider knows what to cache for each language. Convenient, and with the usual trade-off — caching node_modules instead of npm's download directory produces corrupted states when the Node version changes, exactly the invalidation problem of 04-02.
5. script is the deciding phase. Each command in the list runs and if one fails, the following ones run anyway; the build ends up failing. That is different from almost every modern tool, where a failed step cuts the job, and it is a source of confusion when reading logs.
6. after_success does not affect the result. If the coverage upload fails, the build stays green. Sometimes that is what you want and sometimes it hides the fact that you have not uploaded coverage for a month.
7. secure: is a value encrypted with the repository's public key, generated with travis encrypt. Section 5.

An explicit matrix, with what made it powerful:

allow_failures with fast_finish is a good idea that still holds: testing against the language's development version without blocking anybody, and finding out early that something is about to break. It is the equivalent of continue-on-error with the matrix of 02-04.

Fourth translation of the same pipeline, and the first in which we have to explain what cannot be expressed.

What ends up forced, which is the instructive part:

1. The stages are sequential, not a graph. build cannot start until the five jobs in verify finish, even though it only depends on the sources. It is the stage barrier of 04-01 with no way out: there is no needs.
2. Conditionality is limited. The if: language covers branch, event type, tag and environment variables, and little else. There are no path filters like those of 02-07, so the monorepo selective execution of 04-04 cannot be expressed.
3. Sharding means copying and pasting four entries. There is no parallelism: 4 and no matrix that generates shards in one line; each partition is a jobs.include entry with its install and its before_script repeated. Four almost identical blocks: exactly the duplication 04-05 taught you to eliminate and which here has no solution within the file.
4. There is no passing of artifacts between jobs. The dist/ and the image do not travel from the build stage to the publish stage: every job starts on a clean machine. The only way out is to upload the artifact to an external store immediately and download or reference it again later. It works, but it makes the external store a mandatory part of the pipeline and stops the build and the publish from being separable steps.
5. The most serious consequence: because the digest cannot travel, it has to be looked up again by tag. And that breaks a guarantee the course has been defending since 02-06: promotion by digest requires the identifier being promoted to be exactly the one the build produced. Looking it up by tag introduces a window — small, but real — in which that tag could point to a different image. In Travis it can be mitigated (unique tags per commit, registries with immutable tags), not cleanly eliminated.
6. deploy with providers is Travis's most convenient part: dozens of providers (S3, Heroku, npm, PyPI, GitHub Releases) configured in four lines. For publishing an open source package it is still about as direct as anything out there. For deploying to ECS with a canary there is no provider and you end up writing the script anyway.

An honest verdict: the pipeline fits, but it loses the graph, loses declarative sharding, loses selective execution and compromises promotion by digest. It is not that Travis is badly made; it is that it was designed for "build and test an open source project" and this pipeline is continuous delivery.

Stages arrived in 2017, late, and they are sequential groups of parallel jobs — GitLab's original model, without the later needs. They added something important: if: at stage level, and the possibility of a deployment phase after the tests.

Caches: by convention (cache: npm|bundler|pip) or by explicit directories. With two warnings that hold for any tool. First, caching node_modules is a bad idea compared with caching the download directory: node_modules contains binaries compiled for one specific Node version and architecture, and restoring it in another context produces cryptic failures (04-02). Second, invalidating the Travis cache was done by deleting it from the interface or with the CLI, not by changing a key: there is no checksum-based key, so the cache can stay stale indefinitely. It is precisely the control CircleCI made explicit (06-03).

Encrypted secrets, the most characteristic part and the most relevant to what comes next:

The idea was elegant: the encrypted secret lives in the repository, so the .travis.yml is self-contained and works for anyone who forks it without exposing anything, because only Travis has the private key. Two design properties made it reasonably secure: encrypted values are not decrypted in pull request builds from forks — precisely so that a malicious PR could not read them, which is the same reasoning as pull_request_target in 04-03 — and Travis masked the values in the logs.

And in those two properties lies the story of section 7.

The facts, in order, because the pattern matters more than the dates:

January 2019: change of ownership. Travis CI was acquired by Idera. Shortly afterwards there was a significant departure of engineering staff, widely commented on in the community. For users, the immediate effect was uncertainty about the product's direction.

Late 2020: the end of the unlimited free model for open source. A credit system was introduced with a limited allocation for open projects, renewable on request. The justification was reasonable — compute costs are real and abuse through cryptocurrency mining was a genuine problem across the industry — but the change affected the value proposition that had defined Travis for ten years.

2019-2021: GitHub Actions. GitHub launched Actions in the place where most open source projects' code already lived, with generous free minutes for public repositories and zero integration configuration. The combination of both factors produced a mass migration: thousands of projects swapped their .travis.yml for .github/workflows/ci.yml within months.

What you should take from this is not a criticism of Travis or of Idera, but three observations applicable to any tool you choose today:

• Your CI provider's business model can change, and you do not decide it. A free plan, some included minutes or a pricing tier can change with short notice. If your operation depends critically on those conditions, you have an exposure worth acknowledging.
• Integration beats technical quality. Actions did not win by being a better tool than Travis in 2020 — debatable in several respects — but by being where the code already was. It is the criterion 06-07 will put first for its real weight: where the code and the team's identity live decides most choices.
• The cost of leaving is paid when there is no longer an alternative. Projects that kept their logic in scripts in the repository migrated in an afternoon; those that had it scattered through the YAML took weeks. Section 10.

In September 2021, Travis CI published a security advisory about a flaw that caused secure environment variables — including tokens and keys — to be exposed in pull request builds coming from forks of public repositories. That is, the very design property that made the encrypted secret model safe was broken: that a fork cannot access them. Anyone opening a PR against an affected public repository could, with a modified .travis.yml, read secrets that should never have been within their reach.

It was identified as CVE-2021-41077, and the initial communication drew considerable criticism for its scope and detail, which led to a later, more explicit publication. The operational recommendation for any affected public project was to rotate every credential.

Four concrete lessons, none of them about Travis:

1. A secret entrusted to a third party is a secret whose security you do not control. This is not an argument against SaaS — 06-03 mentioned the 2023 CircleCI incident, with the same conclusion of rotating everything, and no platform is immune. It is an argument for assuming it will happen and designing accordingly.

2. Long-lived credentials are the problem; ephemeral ones bound the damage. A leaked permanent access key is valid until somebody revokes it, and that "somebody" usually finds out late. A fifteen-minute OIDC token limited to a specific role (03-02) is stolen material that is already good for almost nothing. This is the practical — not theoretical — reason the course insists so much on federated identity over stored secrets.

3. You have to know how to rotate everything, and have rehearsed it. The useful question is: if tomorrow your provider tells you "rotate all your credentials", how long does it take you and what breaks? If the answer is "I do not know", that is a recovery plan still to be written, exactly in the sense of 03-05. An inventory of secrets with their owner and their rotation procedure is worth a great deal on the day you need it.

4. Forks are the most delicate trust boundary in any CI. The same problem, with a different mechanism, is the pull_request_target issue of 04-03 that 06-06 will return to. The rule is universal and tool-independent: code from a fork cannot access secrets, and any flow that looks like it grants access must be examined under a microscope.

This is the part you will probably actually use. The translation is mostly mechanical, with two or three design decisions.

The four decisions that are not mechanical:

• The distinction between phases that break the build and phases that do not disappears. In Travis, after_success does not affect the result; in the others, a step that fails breaks the job unless you add continue-on-error. When migrating, decide explicitly what should remain non-blocking.
• script with several commands does not stop at the first failure; in the others it does. If your .travis.yml relied on all of them running so as to collect every error at once, you have to reproduce that on purpose.
• secure: secrets are not migrated: they are rotated. They cannot be decrypted without the repository's key in Travis, and even if they could, moving a secret is the perfect moment to change it. And if the repository is public and was active in 2021, rotation is not optional (section 7).
• Take the opportunity to introduce the graph. A one-to-one migration reproduces the waits of the sequential model. This is the moment to add needs and gain time for free.

We start from a realistic .travis.yml, of the kind you will find:

1. on: tags → on: release: publishing when a release is created is more explicit and avoids publishing because of an accidental tag.
2. Explicit permissions are a concept Travis did not have; use the migration to add them (04-03).
3. concurrency cancels stale runs: it did not exist in Travis and it is an immediate saving.
4. fail-fast: false reproduces the usual behaviour of the Travis matrix, where seeing both results was the norm.
5. PostgreSQL as a container with a pinned version and a health check, instead of "whatever the image ships": more reproducible, and it removes the start-up race that in Travis was solved with retries.
6. A deliberate change: node_modules comes out of the cache and ~/.npm goes in. It fixes the binaries problem of 04-02 that the original file was carrying.
7. Uploading coverage with if: always() reproduces the semantics of after_success without breaking the build, but explicitly.
8. needs: [test] is the structural gain: now there is a graph.
9. id-token: write with --provenance adds verifiable provenance to the package (02-06 and 04-03): something that did not exist in Travis's model.
10. environment brings approval and scoped secrets to the publishing step.
11. NPM_TOKEN is a new token. The secure: one is revoked. You do not migrate a secret: you rotate it.

Recommended phases for the migration, with the same criterion as 05-04 — each step with value of its own:

What not to migrate: jobs nobody looks at, matrix entries for versions already out of support — migrating node_js: "0.10" is wasted work — and the after_* phases that have been failing silently for months. A migration is the best opportunity to delete, and wasting it means loading the debt onto the new tool.

Out of the whole Travis episode comes a practical recommendation that 06-07 will develop and that is worth taking on now:

The advantages go beyond migration, and that is why it is worth doing even if you never change tools: the developer can run exactly the same thing on their machine — which eliminates the whole class of "it only happens in CI" failures — the script is tested and reviewed as code, and the YAML stops being a place to hide business logic, which was one of the antipatterns of 04-01.

The honest limit: not everything can be taken out of the YAML. Triggers, the matrix, permissions, environments, concurrency and the cache belong to each tool and cannot be abstracted away without building a layer of indirection that usually costs more than it saves. The reasonable goal is not total portability, it is that 80% of the migration effort should be rewriting orchestration rather than rebuilding logic. The projects that migrated off Travis in an afternoon were the ones with a script: make ci.

Honestly and without nostalgia:

• A project that already has it, works and is not being touched. A stable .travis.yml in a maintenance repository is not an emergency. Migrating costs hours that might pay off better elsewhere. With two conditions: check that the secrets are still valid and necessary, and that the dist: images it uses are still supported.
• Uncommon platforms and architectures. Travis kept support for architectures such as IBM Power, IBM Z and ARM64 earlier and more accessibly than others, and some systems projects still use it for that. If your problem is exactly that, it remains an option worth considering.
• Simple publishing of open source packages. The deploy: block with predefined providers is still about the shortest thing there is for publishing to npm, PyPI or GitHub Releases.

When not to: any new project, any pipeline with real continuous delivery, any team already on GitHub or GitLab, and any case where promotion by digest or selective execution matter. It is not a matter of taste: these are structural limitations of the fixed-phase model, not fixable defects.

Migrating secrets instead of rotating them. Changing tools is the ideal moment to rotate. And if the repository is public and was active in 2021, rotation is mandatory.

Migrating one to one without introducing the graph. It reproduces the waits of the sequential model and wastes the migration's best gain: adding needs.

Copying the node_modules cache across to the new tool. It was bad practice in Travis and it still is. Cache the download directory with a key based on the lockfile.

Forgetting the README badge. It ends up pointing at an inactive service and shows a false status for months. It is cosmetic and it is the first thing anyone arriving at the project sees.

Assuming script stops at the first failure. In Travis it does not; in the others it does. If the order of the commands was hiding failures, the migration will bring them all out at once, and that is a good thing even if it stings on day one.

Leaving Travis active after migrating. It consumes credits, sends notifications nobody reads and keeps alive some secrets nobody controls any more. Disabling the project and revoking credentials is part of the migration, not an extra.

A general tip: when you inherit a .travis.yml, read it as archaeological documentation before translating it. allow_failures tells you what had been broken for a while, the list of dist values and versions tells you when it was last touched, and after_success tells you which integrations existed and perhaps no longer do. That context is worth more than the mechanical translation and it is exactly the approach of 05-04.

Exercise 1. Translate this .travis.yml into GitHub Actions, deciding explicitly which steps should be blocking and which should not, and justify each decision:

Exercise 2. A public repository of your company used Travis between 2018 and 2022 with secure: for an AWS deployment token with broad permissions, an npm token and an SSH key encrypted with encrypt-file. Nobody has touched it since 2022. Write the response plan: what you assume, what you do first, in what order and how you verify you have finished.

Exercise 3. Marta asks: "How much would it cost us to move from GitHub Actions to another tool if their terms change tomorrow?". Design the assessment exercise over Reservalia's ci.yml: how current portability is measured, which changes would improve it, what they cost and how far it is worth going.

Solution 1.

Decisions and their justification. flake8, mypy and pytest are blocking: they are the quality gate of 02-05 and their failure must prevent the merge. The Coveralls upload is non-blocking with continue-on-error because an external service failing says nothing about the code — it is exactly the semantics of after_success, but now explicit instead of implicit in the phase's name. The log dump uses if: failure(), reproducing after_failure.

Two deliberate changes from the original. on: tags becomes on: release so as not to publish because of an accidental tag. And the password: secure: disappears: it is replaced by trusted publishing via OIDC with id-token: write, which removes the long-lived token entirely. It is the change that reduces risk the most in the whole migration, and it is the direct application of the lesson from section 7: the best answer to "stored secrets can leak" is not to store secrets.

A note about cache: pip with cache-dependency-path: without that second line, the key does not include requirements-dev.txt and the cache is not invalidated when the development dependencies change. It is the same incomplete-key mistake as in 04-02.

Solution 2.

What you assume, and it is the most important decision: that all three secrets are compromised. The repository is public, it was active during 2021 and it used exactly the affected mechanism. You do not need to look for evidence of exploitation before acting: the absence of evidence in years-old logs is not evidence of absence, and the cost of rotating is far lower than the cost of being wrong the other way.

Order of action, by potential impact:

1. The AWS token with broad permissions (first, today). Deactivate the key — deactivate before deleting, so you can still investigate — review CloudTrail for the period in case there is activity from unexpected addresses or regions, and replace it. The replacement is not "another key": it is a role assumed via OIDC from your current tool (03-02), with minimum permissions. If there are resources only that key could touch, verify their integrity.
2. The npm token. Revoke it, review the package's published versions in case there is one the team does not recognise — a malicious publication is the worst scenario, because the damage goes to the consumers — and replace it with trusted publishing via OIDC.
3. The SSH key from encrypt-file. Revoke the public key everywhere it is authorised (servers, repository deploy keys), generate a new one, and check the authorized_keys of the reachable servers in case there are keys nobody recognises.
4. Repository cleanup. Delete .travis.yml, the .enc file of the encrypted key and the badge. Careful: deleting does not remove the history, and the encrypted file remains accessible; that is why revocation is the real measure and deletion is only hygiene.
5. Disable the project in Travis so that no credentials remain stored there.

How you verify you have finished: a written inventory of the three secrets with their status — revoked, replaced, verified — a check that no production system depended on them (if something breaks on revocation, it shows up here, which is why you do it during working hours and not on a Friday), and a note in the decision log with the date and the reason. And one underlying action that prevents the next episode: build the organisation-wide inventory of secrets with an owner and a rotation procedure, because this exercise has shown it did not exist.

Solution 3. The exercise is done in three steps and produces a number, not an opinion.

Step 1: classify every line of the ci.yml into three categories.

Step 2: measure. Count the lines in each category across the five workflows and estimate hours. A typical result for a repository like Reservalia: the orchestration is rewritten in 2-4 days; the tied part is the expensive one — every third-party action has to be replaced or reimplemented, the OIDC federation is redone against the new issuer, and the composite actions and reusable workflows are translated to the equivalent mechanism. If 40% of the pipeline is in the "tied" category, the migration is a matter of weeks.

Step 3: improvements and their cost.

How far it is worth going, which is Marta's real question: up to the point where the logic is portable and the orchestration is thin, and not one step further. That is, the first three points yes; the fourth no. The reason is expected cost: the probability of migrating in the next two years is low, but the first three points have immediate benefit regardless of any migration — local reproducibility, a more readable pipeline, reviewable and testable logic, less "false green" from differences between local and CI — whereas the fourth only pays off in an improbable scenario.

The short answer for Marta: "Today, about three or four weeks. With two or three days of work that we could do with anyway for other reasons, we bring it down to a week. And we are not going to try to bring it down to zero, because that costs more than the migration it would avoid."

Travis CI invented the way CI is written today — a file in the repository, convention over configuration, a version matrix — and proved that CI could be a right of any project rather than a privilege of whoever had a Jenkins administrator. Its fixed-phase model was perfect for "build and test" and structurally insufficient for continuous delivery: no graph, no passing of artifacts between jobs, no selective execution and with promotion by digest compromised. Translating the Reservalia pipeline into Travis was the most useful exercise in the module so far, not because the result is usable, but because what does not fit explains why the successors were designed with the graph at the centre.

And the three lessons that outlive the tool: your provider's business model can change and you do not decide it; a secret entrusted to a third party is a secret whose security you do not control, from which it follows that ephemeral federated credentials are not a fashion but a real reduction in damage; and the cost of changing tools is decided years before you change them, according to how much logic you left inside the YAML.

The next lesson changes category. Docker and Kubernetes are not CI tools: they are the substrate modern pipelines run on and the destination they deploy to. We will look at Docker in its two roles — the pipeline's execution environment and the format of the artifact being deployed — go down into what the course had not covered (BuildKit, layer caches in the registry, multi-platform builds, minimal images, building without a privileged daemon), and then on to Kubernetes as the destination: the minimum objects, the probes, rollback with kubectl rollout undo, Helm versus Kustomize, and why GitOps wins in Kubernetes and what changes compared with the push-based cd.yml Reservalia uses.