Skip to content

fix: detect MongoDB version and signing key from the published repo - #41

Merged
stasadev merged 1 commit into
mainfrom
20260813_stasadev_fix_mongo_9
Aug 13, 2026
Merged

fix: detect MongoDB version and signing key from the published repo#41
stasadev merged 1 commit into
mainfrom
20260813_stasadev_fix_mongo_9

Conversation

@stasadev

@stasadev stasadev commented Aug 13, 2026

Copy link
Copy Markdown
Member

The Issue

https://github.com/ddev/ddev-mongo/actions/runs/31685388982

Installing the MongoDB CLI tools failed with gpg: no valid OpenPGP data found. The signing key name does not track the release version: every 8.x release is signed with server-8.0, but 9.x uses server-9. The key was derived as <major>.0, so once 9.0 was published as the latest release the build requested server-9.0.asc, which does not exist, and wget -qO- piped the 404 page into gpg.

The version was also taken as the newest suite in the bucket without checking it was usable, and 9.0 shipped mongodb-database-tools before mongodb-mongosh was available for it.

How This PR Solves The Issue

  • Look the key name up in the pgp.mongodb.com bucket listing instead of deriving it from the version.
  • Select the newest release whose Packages index actually lists every package for TARGETARCH, so an incomplete or arch-specific suite is skipped before the repository is configured.
  • Fetch with curl -f so an HTTP error fails at the download rather than feeding an error page to gpg.
  • Fall back to a known-good version/key pair when either bucket listing is unreachable or returns nothing usable, so the build still installs.

Manual Testing Instructions

ddev add-on get ddev/ddev-mongo --pr 41
ddev restart
ddev exec mongosh --version
ddev exec mongodump --version

Automated Testing Overview

Covered by the existing bats tests, which assert mongosh and mongodump are available in the web container.

20260813_stasadev_fix_mongo_9

## The Issue

Installing the MongoDB CLI tools failed with `gpg: no valid OpenPGP data
found`. The signing key name does not track the release version: every
8.x release is signed with `server-8.0`, but 9.x uses `server-9`. The key
was derived as `<major>.0`, so once 9.0 was published as the latest
release the build requested `server-9.0.asc`, which does not exist, and
`wget -qO-` piped the 404 page into `gpg`.

The version was also taken as the newest suite in the bucket without
checking it was usable, and 9.0 shipped `mongodb-database-tools` before
`mongodb-mongosh` was available for it.

## How This PR Solves The Issue

- Look the key name up in the `pgp.mongodb.com` bucket listing instead of
  deriving it from the version.
- Select the newest release whose `Packages` index actually lists every
  package for `TARGETARCH`, so an incomplete or arch-specific suite is
  skipped before the repository is configured.
- Fetch with `curl -f` so an HTTP error fails at the download rather than
  feeding an error page to `gpg`.
- Fall back to a known-good version/key pair when either bucket listing is
  unreachable or returns nothing usable, so the build still installs.

## Manual Testing Instructions

```bash
ddev add-on get ddev/ddev-mongo --pr replace_me
ddev restart
ddev exec mongosh --version
ddev exec mongodump --version
```

## Automated Testing Overview

Covered by the existing bats tests, which assert `mongosh` and `mongodump`
are available in the web container.

## Release/Deployment Notes

Only affects the web container build. Selection is dynamic, so no change
is needed here when MongoDB publishes a new release.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@stasadev
stasadev merged commit 35d60bf into main Aug 13, 2026
2 of 4 checks passed
@stasadev
stasadev deleted the 20260813_stasadev_fix_mongo_9 branch August 13, 2026 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant