Something like:
Applications in Fedora Infrastructure may be deployed via non rpm
methods (as long as they obey licensing guidelines (
https://fedoraproject.org/wiki/Infrastructure_Licensing )). For those
applications, creating and maintaining an rpm is optional.
How about:Applications in Fedora Infrastructure need to be deployed in an auditable and repeatable way. These methods need to allow someone to determine which software was installed, when it was installed, and what it was meant to be done (example: rpms or podman build scripts for containers). The goal is to be kind to our future selves at 2 am who need to figure out why a critical application is broken and how to rebuild and redeploy as needed.
Yeah that seems sensible (although I'm not sure of the wording of "what it was meant to be done", but I think I get it).
This would satisfy apps built with s2i as long as they are pinning their dependencies with something like poetry or pipenv. We are currently standardizing on poetry but any would do as long as deps are pinned).
For s2i based apps, I see two ways of ensuring repeatability, one being stricter but more transparent than the other:
1. have the buildconfig track a production branch upstream, and rely on the build log to know which exact commit was built
2. have the buildconfig specify the commit hash, and change the buildconfig each time we want to deploy a new prod version
Option 2 is more transparent because the commit to build is a var in ansible, but it means updating ansible each time we want to make a prod deployment.
The workflow for option 1 is simpler because it's just a start-build, but we'll need the logs to know which commit in the prod branch was actually built, and it may be cumbersome to dig up during if something goes wrong.
Any preference? As a dev I would be happy with both, they are still infinitely easier than building RPMs. Option 1 being easier for devs, my lazy self leans towards it, but Option 2 is fine as well.
Another option that I did not think of?
Aurélien
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
