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 <[email protected]> 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 <[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
>
