Johannes Haass
Johannes Haass
One problem I see is that we'll never know which is the 'old' and the 'new' version. Also in cf-deployment some capi releases are skipped. Another option (maybe mid/long term)...
I modified `enqueuer` to serialize jobs (`job.to_yml`) and executed the unit tests. Unfortunately not all jobs are covered (e.g. `SpaceApplyManifestActionJob`) and also the jobs are not as nested compared to...
Same issue occurs with CLI v8.0.0 + with the following env variable: ``` YAML env: SOME-ENV: "{{\"my-json\":\"value\"}}" ```
This also happens if a user was created with `uaac` but not (yet) used with CF CLI (e.g. with `cf auth`). Can be reproduced with: ``` $ uaac user add...
The PR does not seem to fix the problem, there are still errors.
The ruby version in the devcontainer image was not pinned to 3.2 and therefore used the latest ruby version 3.3. I fixed it with https://github.com/cloudfoundry/cloud_controller_ng/commit/e8ac7e01f828e9f247b9dbed07a3a7ae3ca2225d @vipinvkmenon Please try again
Side note: There are [parameters](https://github.com/cloudfoundry/capi-release/blob/develop/jobs/cloud_controller_ng/spec#L709-L714) like `max_migration_duration_in_minutes` and `max_migration_statement_runtime_in_seconds` (only for psql) which allow operators to limit the total duration of migrations.
Would be great to have a new release/tag. Would allow us to move a way from a forked version.
@dependabot rebase
Would require manual validation on alicloud