Use adminerevo docker image instead of the deprecated adminer image, fixes #27

[M-arcus]

The Issue

• consider updating this to adminerevo now #27

How This PR Solves The Issue

It uses the adminerevo docker image

Manual Testing Instructions

For DDEV v1.23.5 or above run

ddev add-on get https://github.com/M-arcus/ddev-adminer/tarball/adminerevo

For earlier versions of DDEV run

ddev get https://github.com/M-arcus/ddev-adminer/tarball/adminerevo

Afterwards run ddev restart

Then you can just ddev adminer or use ddev describe to get the URL (https://<project>.ddev.site:9101).

Automated Testing Overview

See the GitHub Action https://github.com/M-arcus/ddev-adminer/actions/runs/11956882733

Related Issue Link(s)

• Issue: consider updating this to adminerevo now #27
• Feature request on ddev repo: Feature Request: Adminerevo addon for ddev ddev#6754
• Discussion about Docker image: docker images adminerevo/adminerevo#22

Release/Deployment Notes

• Does the readme need to be rewritten because of the name?
• Is the choice of the docker image correct?

[rfay]

Your testing instructions are not correct as they point to a release on your fork.

Instead, they should be

ddev add-on get https://github.com/M-arcus/adminerevo/tarball/adminerevo

But in general, please don't use the branch main for a PR. That means that you can't ever change main on your fork.

And I don't think you'll want to be introducing the actual contents of your edited add-on, instead focus on the actual changes.

Maybe it would be best to create a new branch that focuses on being a PR?

[M-arcus]

This PR was created with the branch https://github.com/M-arcus/ddev-adminer/tree/adminerevo, not with main.

[M-arcus]

And I don't think you'll want to be introducing the actual contents of your edited add-on, instead focus on the actual changes.

What edited contents are meant?

[rfay]

Your manual testing instructions say to use ddev add-on get M-arcus/ddev-adminer

That will get a released version of the fork, not the current branch.

Sorry I didn't read your branch correctly, I edited my suggestion for the testing instructions, which will get your actual branch.

[rfay]

Thanks for working on this!

The Dockerfile is obsolete, so you can remove the build section of the docker-compose.adminer.yaml and instead add an image statement.

[rfay]

This file serves no purpose here (that I can understand). It should just be removed, and the docker-compose.adminer.yaml should use the upstream image.

[M-arcus]

I have removed the file, added the image to the docker-compose.adminer.yaml and updated the install.yaml

[M-arcus]

I have updated the manual testing instructions in the initial comment.

[rfay]

In its current state, after you add the image back into docker-compose.adminer.yaml, you can remove the adminerevo directory.

[rfay]

Are you confident that adminerevo is the most likely successor to adminer?

[rfay]

The tests (https://github.com/ddev/ddev-adminer/blob/main/tests/test.bats) look pretty limited, it's worth considering looking at them in this or a followup PR.

[M-arcus]

Are you confident that adminerevo is the most likely successor to adminer?

Yes, it is often recommended and supports a wide range of technologies.

[bserem]

Suggested change

	This repository allows you to quickly install the Adminerevo fork of the adminer database manager into a [Ddev](https://ddev.readthedocs.io) project using just `ddev get ddev/ddev-adminer`.
	This repository allows you to quickly install the [AdminerEvo](https://docs.adminerevo.org/) fork of the [adminer](https://www.adminer.org/) database manager into a [DDEV](https://ddev.readthedocs.io) project using just `ddev get ddev/ddev-adminer`.

[bserem]

Suggested change

	Adminer is available for MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Oracle, Elasticsearch and MongoDB.
	AdminerEvo is available for MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Oracle, Elasticsearch and MongoDB.

[rfay]

How about "Adminer works with"

Moving to mention of AdminerEvo may end up adding confusion. I know we're changing the technology behind this. Should we just mention that in the README and then still use regular adminer terminology?

[bserem]

I like that idea

[bserem]

can we set a predefined DB here?

[bserem]

Hey @M-arcus , thanks for the initiative and the work on updating this! I honestly was unaware of the changes in the adminer world.

The new version of the add-on works ok for me.

I am only wondering if we can set a predefined DB.
It wasn't possible with the original version either but @wotnak solved this in #1

[rfay]

Oh, the usage of ddev get is outdated, should be ddev add-on get.

And normally we encourage people to use a .ddev/docker-compose.adminer_extras.yaml that they control rather than editing the docker-compose.aadminer.yaml. That way they profit from future changes to the add-on without having to think about re-applying edits.