On Tue, May 24, 2022 at 06:24:10PM +0200, Aurelien Bompard wrote: > > 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 A third option which we've used in a few of our apps is to have a specific branch (or branches) for our deployment. That branch can then have commits dedicated to our deployment, such as support for s2i which aren't needed in the 'main' branch. We could do things like the version pining in that branch as well, making it easy/easier for people to package the application while still helping us ensure the reproducibility we want in openshift. Pierre _______________________________________________ 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
