Hi Adam, > On 19. Nov 2021, at 17:00, Adam Kocoloski <kocol...@apache.org> wrote: > > Now that we’re getting closer to producing release candidates for some of > these component libraries, I’m wondering about where they ought to be > uploaded. Maybe a “components” directory alongside the top-level “source” and > “binary” directories that we use for CouchDB artifacts? E.g. > > source/ > 1.2.2/ > … > binary/ > mac/ > win/ > components/ > b64url/ > source/ > 1.1.0/ > erlfdb/ > … > > Alternatively we could have top-level directories like “couchdb-b64url” as > peers to “couchdb", but that seems to head down the path of treating these > things as separate projects instead of separate releases, and that’s an > overhead I think we’d want to avoid. > > Any strong opinions on this front?
The proposal looks good to me. Best Jan — > > Adam > >> On Nov 19, 2021, at 9:22 AM, Adam Kocoloski <kocol...@apache.org> wrote: >> >> 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 <woh...@apache.org> 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 <jo...@jsent.ca> 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 >> >
