top of page
Search
  • Akmod

Idem's Automated Release Process

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
  1. pop-release stage: Declares that the pipeline uses the pop-release stage from the included template

  2. include project: Brings in the pop-release CI/CD template from saltstack.

  3. 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:

  1. Master Branch: Ensures that only code from the master branch is released. No nasty surprises here.

  2. Isolated Environment: The build takes place in a sterile CI/CD environment, safeguarding the integrity of the release.

  3. 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


bottom of page