Ever found yourself digging through .gitlab-ci.yaml in one of our idem-based projects and wondering what all those lines of code are doing? Well, you're in the right place.
The .gitlab-ci.yaml File
If you have poked around in any of the .gitlab-ci.yaml files in a pop project, you may have seen the "pop-release" stage. Let's talk about the release stage of the pipeline and how it works. Here's the config file you'll commonly see in our repositories:
stages:
- pop-release
include:
- project: saltstack/pop/cicd/ci-templates
file: /release/pop_release.yml
variables:
CICD_UPSTREAM_PATH: "vmware/idem/<idem-project>"What It Does
pop-release stage: Declares that the pipeline uses the pop-release stage from the included template
include project: Brings in the pop-release CI/CD template from saltstack.
CICD_UPSTREAM_PATH variable: Declares the location of the upstream path in gitlab. The pipeline uses this variable to determine if it is running on the upstream repo.
The Significance of Protected Tags
Maintainers create version tags like "v1.0.0" on the upstream POP repository, and these tags trigger the release pipeline. Those tags are only able to be created by maintainers, which ensures that only legit releases are processed.
The Role of pop-release
pop-release is an POP project that kicks in during this stage. It's responsible for packing the code and preparing it for PyPi in a clean environment. And no, you can't use SaltBot for your own python project releases—this is an internal tool that only works in the vmware and saltstack gitlab spaces.
Why This Matters
Releasing from the pipeline has several advantages:
Master Branch: Ensures that only code from the master branch is released. No nasty surprises here.
Isolated Environment: The build takes place in a sterile CI/CD environment, safeguarding the integrity of the release.
Consistency: By avoiding the quirks and inconsistencies of local dev environments, the release is as clean as it gets.
This setup safeguards our releases, making sure they meet the highest standards of code quality and stability.
Conclusion
So there you have it—a full transparency report on how we manage releases for idem-based projects. Hopefully, this clears up any questions you might have had. Feel free to poke around and see how we do things; after all, open-source thrives on community engagement.
Comments