Intriguing. Looks like Airflow is using GHCR pretty extensively alongside their GHA-based CI. It does make good sense to me to advertise an image alongside the repo as a Quickstart that contains all the dependencies necessary to build the software. Not the most urgent thing, but I’ll add it to the list :)
Adam > On Nov 18, 2021, at 6:21 PM, Joan Touzet <[email protected]> wrote: > > FYI: while GH Releases is discouraged for any apache repo, GHCR is apparently > acceptable. So perhaps this is an option for your containers? > > https://github.com/apache/yetus/pkgs/container/yetus > https://github.com/apache/yetus/pkgs/container/yetus-base > > reference: > > https://lists.apache.org/thread/66hhhn2t3mx7mg2j9ls4656ngl7j3n0h > > HTH, > Joan > > On 17/11/2021 08:31, Adam Kocoloski wrote: >>> On Nov 17, 2021, at 12:22 AM, Joan Touzet <[email protected]> wrote: >>> >>>>> Do we really think these apps are going to have a lot of churn and need a >>>>> lot of releases? >>>> >>>> I could see `erlfdb` needing a regular release cadence, but I’m willing to >>>> see what can be done to comply with the ASF regulations in a >>>> semi-automated way. The other repos we’ve been discussing are somewhat >>>> more stable, although part of the motivation for publishing packages is to >>>> drive more interest in them and that could lead to more releases. >>>> >>>> Tangentially-related question for you: one of the CI jobs for erlfdb is >>>> using a container image built from this Dockerfile: >>>> >>>> https://github.com/apache/couchdb-erlfdb/blob/main/.devcontainer/Dockerfile >>>> >>>> Should I publish that image as a tag in apache/couchdbci-debian, even >>>> though it’s basically a completely different build than the other images >>>> in there? Creating a whole new e.g. apache/erlfdbci repo for it seems like >>>> overkill, but I’m curious to hear your thoughts. Would something like this >>>> work? >>>> >>>> apache/couchdbci-debian:erlfdb-erlang-24.1.4-fdb-6.3.18 >>>> >>> >>> I guess you can't merge it with the other images directly? >>> >>> No objection to using the tagging approach you outline above, of course. >>> But looking at other image names in the apache Docker Hub org, I think >>> Infra would readily approve another name if you need it. >>> >>> -Joan >> I think maybe I could use those existing images? I vaguely recall when I was >> first building a .devcontainer configuration for CouchDB I tried to start >> from the images in couchdbdev and ran into an issue I couldn’t sort out. I >> think it had something to do with the interaction with the erlang_ls plugin >> for VS Code. But I could take another pass at that at some point. There are >> a couple of notable differences in the erlfdb image: >> - FDB server is not installed, instead CI configures FDB to run alongside in >> a service container >> - Image contains a shallow clone of the FDB source code since that’s where >> the binding tests are defined >> - No extra CouchDB dependencies, e.g. Node, Elixir, SpiderMonkey … probably >> leads to faster build times >> I do quite like the idea that the .devcontainer and the CI image used for >> that part of the erlfdb test suite are identical, it just cuts off a whole >> branch of debugging questions. I’ll go ahead and use a tag like the one >> above for now, and if erlfdb or other Erlang apps start proliferating we can >> see about another Docker repository. Thanks, >> Adam
