Repository navigation
API exact match on arch field #295
Description
Manually extracted from #289 (comment)
There are exactly 2 choices of arch: amd64 | arm64, plus end users may want to filter results down to multi-arch images (e.g. mix phx.gen.release needs that), thus making an array also a reasonable valid input, thus making "arch": "amd64" | "arm64" | ["amd64", "arm64"].
LiveView UI in /docker uses a dropdown, so values are always exact and no typing is required.
One way to make arch usable for multi-arch queries is turning it into a multi-select in the LiveView UI (or, perhaps even better UX, keep with a single select with options "any", "amd64", "arm64", "multi-arch"), and an (optional) list of strings in the API, so that we can query for images that have both amd64 & arm64 archs.
An alternative for the API would be accepting some special value like "all", but I'd argue that's a worse solution, because it is ambiguous. If in the future Bob supports a new arch, the meaning of "all" would suddenly change.
Suggestion: make arch exact match instead of prefix match and support list of archs as API input, similar to the change to repo in #289.
Activity
ericmj commentedon Sep 5, 2026
Agreed, lets do this.
rhcarvalho commentedon Sep 10, 2026
I'm working on it.
@ericmj I noticed
sortsupports a comma-separated list of options, but not the traditional Plug syntaxsort[]=...&sort[]=.... Was that an intentional design decision?For consistency, I'm intending to follow the same pattern for
arch. Examples:arch=amd64: means tag containsamd64, so both single an multi-arch images may be returned.arch=amd64,arm64: means tag contains both architectures.The idea is that API/UI users specify which platforms they care about (e.g. development/production target platform architectures).
Instead of prefix match we do array containment in Postgres.
And for the UI, the dropdown will show
amd64 + arm64, which I believe is unambiguous, particularly if we ever introduce a third supported architecture to Bob.ericmj commentedon Sep 21, 2026
The comma format for
sortwasn't intentional. Can you switchsortto Plug's bracket format (sort[]=elixir_version&sort[]=erlang_version) when you do thearchchanges, and use the same format forarch(arch[]=amd64&arch[]=arm64)? Update docs/api.md for both, with a note about the old comma format like #293 added forrepo.rhcarvalho commentedon Sep 21, 2026
Released Phoenix versions rely on the comma syntax:
https://github.com/phoenixframework/phoenix/blob/v1.8.14/lib/mix/tasks/phx.gen.release.ex#L333
(used in
mix phx.gen.release --docker)How about we support both syntaxes? Keeps backwards compatibility and the comma separated list is clearer to read/copy-paste the URL. In fact, we could continue not supporting the bracket syntax unless there's demand for it? (my earlier comment doesn't count as demand for it :) )