bQUARKz
3453494341
Reviewed-on: #10 Co-authored-by: bQUARKz <bquarkz@gmail.com> Co-committed-by: bQUARKz <bquarkz@gmail.com>
36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
---
|
|
id: LSN-0020
|
|
discussion: DSC-0019
|
|
title: Lesson - Jenkins CI Standardization and Relocation
|
|
status: done
|
|
created: 2026-04-07
|
|
resolved:
|
|
tags: ["ci", "jenkins", "devops"]
|
|
---
|
|
|
|
# Lesson - Jenkins CI Standardization and Relocation
|
|
|
|
## Context
|
|
|
|
The project had a `Jenkinsfile` stored in a non-standard location (`files/config/Jenkinsfile`) with outdated configurations and divergent build commands compared to the project's `Makefile` and GitHub Actions.
|
|
|
|
## Problem
|
|
|
|
- **Discoverability**: Configuration files in unexpected directories increase the mental load for new contributors.
|
|
- **Divergence**: Maintenance becomes harder when the same logic (how to build/test the project) is duplicated in multiple places with different flags.
|
|
|
|
## Solution
|
|
|
|
The `Jenkinsfile` was moved to the project root, following standard Jenkins conventions. Its content was updated to delegate the actual work to the `Makefile` (command `make ci`).
|
|
|
|
## Key Takeaways
|
|
|
|
1. **Standardize over Innovate**: Unless there's a strong technical reason, keep infrastructure files in their canonical locations (e.g., `Jenkinsfile` at root).
|
|
2. **Centralize Build Logic**: Use a `Makefile` or similar tool to define the canonical way to build and test the project. CI pipelines should merely invoke these commands. This ensures that CI behavior can be reproduced locally by any developer.
|
|
3. **Environment Parity**: By using the same Docker image and commands across different CI providers (Jenkins and GitHub Actions), we reduce "it works on my CI" issues.
|
|
|
|
## References
|
|
|
|
- [DEC-0002: Jenkinsfile Location and Strategy](../../workflow/decisions/DEC-0002-jenkinsfile-strategy.md)
|
|
- [Makefile](../../Makefile)
|