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? 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 >