3151: Fix sentry backend release

[f1sh1918]

Short Description

Currently we get in sentry only release with version 1.0.0 instead of the real version number that we pass to gradle in the build process. The problem appears to be that the build process starts before the version bump is finished, so no release version number is available and it uses the fallback.

Proposed Changes

• build backend after version bump in delivery workflows
• use isReleaseBuild system environment variable to distinguish between test builds (commit_main) and release builds
• filter sourceSets to deliver stack traces to sentry only for main package
• set release build environment variable in circle ci
• remove expensive layer caching for test containers (it makes only sense for custom docker images) -> tests are not slower, see example with caching here
• remove setup_remote_docker from build_backend since distJar runs no tests
• throw error if release builds have no NEW_VERSION_NAME

Side Effects

• N/A

Testing

Resolved Issues

Fixes: #3151

[deliverino]

LLM Review (verdigado-think)

General Assessment

The PR focuses on refining the CI/CD pipeline and the backend build process, specifically regarding how release builds are handled, versioning is enforced, and Sentry source bundles are uploaded.

Backend (Build Configuration)

The changes in backend/build.gradle.kts are well-reasoned:

• Version Safety: The logic for versionName now explicitly fails the build if NEW_VERSION_NAME is missing during a release build (isReleaseBuild == true), while providing a sensible 0.0.0-dev default for non-release builds. This prevents the accidental deployment of artifacts with ambiguous versioning.
• Sentry Optimization:
  • Moving the sentry { ... } block and the sentryUploadSourceBundleJava task trigger behind the isReleaseBuild flag is a good optimization to reduce CI runtime and Sentry noise.
  • Restricting sentrySourceDirs to sourceSets.main avoids uploading test code to Sentry, which keeps the source context clean and reduces bundle size.
• Task Dependencies: Properly adding dependsOn(tasks.generateBuildConfigClasses) to Sentry tasks ensures that generated constants are available before the bundle is created.

CI/CD (CircleCI)

• Workflow Correctness: In .circleci/config.yml and the separate workflow files, build_backend now correctly requires: [bump_version]. Since the version name is baked into the build via BuildConfig, the version bump must occur before the build starts.
• Parameterization: The introduction of the release parameter in the build_backend job allows the same job definition to be used for both standard CI checks and production deliveries.
• Resource Management: Removing docker_layer_caching: true aligns with the commit message regarding "expensive layer caching," suggesting a move toward a more efficient or alternative caching strategy.

Commit Messages & Labels

• Commit Messages: All messages follow the project convention (<issue>: <message>), use the present tense, and are descriptive.
• Labels: The maintenance label is correctly applied as these changes affect build infrastructure and have no direct user-facing effect.

Security & Quality

• No secrets are committed; the build relies on environment variables (e.g., SENTRY_BACKEND_AUTH_TOKEN) provided by CircleCI contexts.
• No changes were made to business logic, so no new tests are required.

[andrew8er]

We should always fail in such situations, a fallback is not helpful here.

[f1sh1918]

So for test builds you always have to provide a version number?

[andrew8er]

I meant that for production builds a missing version number should fail or at least produce an immediately recognizable wrong version number.

[f1sh1918]

I meant that for production builds a missing version number should fail or at least produce an immediately recognizable wrong version number.

i've also realized that we are not properly uploading sentry related meta infos
https://app.circleci.com/pipelines/gh/digitalfabrik/entitlementcard/11319/workflows/7cbfe55d-9c60-4a0a-80be-edc44ac902ea/jobs/65906/parallel-runs/0/steps/0-109
i think the CI property should be system env

[andrew8er]

Mh, I don't get what you mean from the linked output.

On a completely other note: why are we using docker layer caching here? Completely unnecessary and crazy expensive.

[f1sh1918]

Mh, I don't get what you mean from the linked output.

On a completely other note: why are we using docker layer caching here? Completely unnecessary and crazy expensive.

That's a log from dev delivery and all sentry related things were skipped which should not be

[andrew8er]

So distTar does not include any Sentry-related tasks?

[f1sh1918]

@andrew8er and @seluianova
It looks like that our Sentry.init in the SentryConfig is not sufficient for tracing (Performance monitoring)
We still have this leftover in the application-staging.properties

Afaics we only have transactions for staging:
https://sentry.tuerantuer.org/organizations/digitalfabrik/explore/discover/homepage/?dataset=transactions&environment=staging&field=title&field=project&field=user.display&field=timestamp&name=All%20Errors&project=7&query=&queryDataset=transaction-like&sort=-timestamp&statsPeriod=24h&yAxis=count%28%29

The issue was when i remember right that we couldn't set the version number via properties file
I will create a follow up issue: #3157

[andrew8er]

The Sentry plugin does need a lot of hand holding for basic tasks.

Looks good.

[seluianova]

looks good, thanks for tackling this!