u/backbonehq

After bumping to Quarkus **3.38.0** I'm hitting a hard failure during `@QuarkusTest` boot:

java.lang.NoSuchMethodError:
'void io.quarkus.vertx.core.deployment.VertxOptionsConsumerBuildItem.<init>(java.util.function.Consumer, int)'
at io.quarkiverse.micrometer.registry.deployment.binder.VertxBinderProcessor.build(...)

Maven GAVs

io.quarkus.platform:quarkus-bom:3.38.0

io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-prometheus-v1:3.5.0 (latest)

In Quarkus 3.38, `VertxOptionsConsumerBuildItem` was changed to require a third `orderKey` argument:

new VertxOptionsConsumerBuildItem(consumer, priority, orderKey)

Quarkiverse **prometheus-v1 3.5.0** still does the old 2-arg call (and looks built against ~3.31.x). There’s no newer prometheus-v1 release on Maven Central yet.

Has anyone else hit this on Quarkus ≥ 3.38 with prometheus-v1?

How did you deal with it? Switch back to platform `io.quarkus:quarkus-micrometer-registry-prometheus`, or something else? Switching to the legacy simpleclient registry is deprecated and Quarkus 4 is a year away it seems... :/

Is there a tracked Quarkiverse issue / upcoming release for 3.38 compatibility I can follow?

I'm using GitHub Environments (`INT`, `STAGE`, `PROD`), each with its own `AWS_ACCOUNT_ID`. Works great when a job targets one environment - assume the right role, deploy to that account.

The central ECR registry is in INT env. STAGE/PROD ECS tasks need to pull from that registry, so at CDK synth time we need:

1. INT’s account ID (where the images live)
2. INT + STAGE + PROD account IDs (ECR repo policy principals)

The snag: Environment variables are only available to the jobs that declare that Environment. A job with `environment: STAGE` can see STAGE’s `AWS_ACCOUNT_ID`, but not INT’s. So I can’t just write `${{ vars.AWS_ACCOUNT_ID }}` for “the INT account” while deploying STAGE.

I’d rather not invent a parallel config surface if Environments already hold the source of truth.

How is everyone else solving “job in env X needs a non-secret config value from env Y” - especially for central registry / multi-account AWS setups?

I'm using GitHub Environments (INT, STAGE, PROD), each with its own AWS_ACCOUNT_ID. Works great when a job targets one environment - assume the right role, deploy to that account.

The central ECR registry is in INT env. STAGE/PROD ECS tasks need to pull from that registry, so at CDK synth time we need:

1. INT’s account ID (where the images live)
2. INT + STAGE + PROD account IDs (ECR repo policy principals)

The snag: Environment variables are only available to the jobs that declare that Environment. A job with environment: STAGE can see STAGE’s AWS_ACCOUNT_ID, but not INT’s. So I can’t just write ${{ vars.AWS_ACCOUNT_ID }} for “the INT account” while deploying STAGE.

I’d rather not invent a parallel config surface if Environments already hold the source of truth.

How is everyone else solving “job in env X needs a non-secret config value from env Y” - especially for central registry / multi-account AWS setups?