What My First CI Pipeline Caught

Written by

in

,

After my lab was running, I put the code on GitHub and set up a CI (continuous integration) pipeline with GitHub Actions. My very first pull request failed. Here’s what happened.

What my pipeline checks

Every pull request automatically runs:

  • terraform fmt: is the code formatted correctly?
  • terraform validate: is the configuration valid?
  • TFLint: common Terraform mistakes
  • Checkov: a security scan of the infrastructure code
  • ansible-lint: Ansible best practices

What failed

All the Terraform checks passed. The last step, ansible-lint, failed with two errors like this:

fqcn[canonical]: You should use canonical module name
`ansible.mysql.mysql_db` instead of `community.mysql.mysql_db`.

The MySQL modules I used have a newer official name. The linter wanted the new one.

The decision

The obvious fix was to rename the modules. But first I checked whether my own Ansible had the new names:

ansible-galaxy collection list ansible.mysql

It printed nothing. My laptop only had the older names, and that version was the one I had tested and knew worked. Renaming would have passed the linter but broken my actual deployments.

So instead, I added the rule to my lint config as a documented exception, and kept the working code. I’ll switch to the new names once my local setup supports them.

A second fix

I also noticed every check ran twice: once for the push and once for the pull request. I changed the pipeline to run only on pull requests.

The result

All checks were successful
0 cancelled, 0 failing, 1 successful, 1 skipped, and 0 pending checks

What I learned

CI didn’t just catch a problem. It made me read the log and make a real trade-off between following a rule and keeping working code.