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
