Rework release workflows for components

Zelldon commented 3 weeks ago

Description

With 8.6-alpha1 we target the single jar and recently we merged Operate into multi-maven project.

Both have an impact on how we release the components (current dry-runs are failing), likely we need to rework/join the release procedures as we want to build/release them together.

Zelldon commented 2 weeks ago

Working run (for Zeebe QA):

    [INFO] --- failsafe:3.2.5:integration-test (default) @ zeebe-qa-integration-tests ---
Warning: ING]  Parameter 'systemProperties' is deprecated: Use systemPropertyVariables instead.
    [INFO] Tests are skipped.
    [INFO] 
    [INFO] --- jacoco:0.8.12:report (coverage-report) @ zeebe-qa-integration-tests ---
    [INFO] Skipping JaCoCo execution because property jacoco.skip is set.
    [INFO] 
    [INFO] --- gpg:1.6:sign (sign-artifacts) @ zeebe-qa-integration-tests ---
    [INFO] 
    [INFO] --- failsafe:3.2.5:verify (default) @ zeebe-qa-integration-tests ---
    [INFO] Tests are skipped.

Failing output for Operate QA:

  [INFO] --- gpg:1.6:sign (sign-artifacts) @ operate-qa-it-tests ---
    gpg: signing failed: Cannot allocate memory
    gpg: signing failed: Cannot allocate memory
    gpg: signing failed: Cannot allocate memory
    gpg: signing failed: Cannot allocate memory
    [INFO]

So either the problem is that the Operate QA might include to many files, like node modules (?) or it is because we built everything in parallel?

I would need to verify this.

Zelldon commented 2 weeks ago

Changing the concurrency (reducing it from thread per core to half thread per core) seems to allow the release dry run to succeed.

https://github.com/camunda/zeebe/actions/runs/8690933557

See #17474

Zelldon commented 2 weeks ago

Might make sense to exclude some modules on release like qa where we generate unnecessary gpg and lose time etc https://stackoverflow.com/a/22783674

camunda / zeebe

Rework release workflows for components #17435

Description