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