Closed machacekondra closed 3 months ago
Build succeeded. https://ansible.softwarefactory-project.io/zuul/buildset/fb6d583de8ad45719dac949dc8fcdc5c
:heavy_check_mark: ansible-test-cloud-integration-vmware-rest SUCCESS in 15m 18s :heavy_check_mark: build-ansible-collection SUCCESS in 11m 16s :heavy_check_mark: tox-cloud-refresh-examples-vmware SUCCESS in 10m 58s :heavy_check_mark: ansible-galaxy-importer SUCCESS in 4m 49s
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 34.20%. Comparing base (
010fef0
) to head (e89927e
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Build succeeded. https://ansible.softwarefactory-project.io/zuul/buildset/477f8e85d12749798cfb879ebcabe7c1
:heavy_check_mark: ansible-test-cloud-integration-vmware-rest SUCCESS in 14m 44s :heavy_check_mark: build-ansible-collection SUCCESS in 10m 54s :heavy_check_mark: tox-cloud-refresh-examples-vmware SUCCESS in 11m 08s :heavy_check_mark: ansible-galaxy-importer SUCCESS in 4m 51s
Merge Failed.
This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Build succeeded. https://ansible.softwarefactory-project.io/zuul/buildset/ce45e0c7dea946e997c4e8ee390e4bfb
:heavy_check_mark: ansible-test-cloud-integration-vmware-rest SUCCESS in 15m 33s :heavy_check_mark: build-ansible-collection SUCCESS in 11m 47s :heavy_check_mark: tox-cloud-refresh-examples-vmware SUCCESS in 11m 14s :heavy_check_mark: ansible-galaxy-importer SUCCESS in 4m 47s
Everything appears good. However, I would prefer this PR to exclusively contain the release-related modifications. Would it be possible to split this PR, moving the module and documentation changes to a separate one? Once the other PR is merged, we can rebase this release PR. @mariolenz @alinabuzachis Your thoughts?
Everything appears good. However, I would prefer this PR to exclusively contain the release-related modifications. Would it be possible to split this PR, moving the module and documentation changes to a separate one? Once the other PR is merged, we can rebase this release PR. @mariolenz @alinabuzachis Your thoughts?
Any changes to the modules are the reflection of the content_builder's changes. As far as I know, documentation regeneration is part of the prep release PR as a consequence of plugins regeneration. We used to include all these in a prep release PR ( for example: https://github.com/ansible-collections/vmware.vmware_rest/pull/451)
The relevant changes are in specific commit, but in single PR, so all relevant changes will be nicely seen in git history. But if needed it may be split into two PRs. But I think it's not an issue here. The issue here is that we don't which content_builder commit was used to do this release I think that would simplify the review a lot, because we would have PRs like bump to content_builder 1.0.x. So I think this is a good time to talk about versioning the content_builder, to make the releases more predictable.
The relevant changes are in specific commit, but in single PR, so all relevant changes will be nicely seen in git history. But if needed it may be split into two PRs. But I think it's not an issue here. The issue here is that we don't which content_builder commit was used to do this release I think that would simplify the review a lot, because we would have PRs like bump to content_builder 1.0.x. So I think this is a good time to talk about versioning the content_builder, to make the releases more predictable.
My request to split this PR is aimed at enhancing the clarity regarding the intent and scope of these modifications for the stakeholders. While this request is optional, I would prefer to adopt it for future changes. Additionally, including a changelog that outlines how the alterations in content_builder have influenced module and documentation generation would facilitate future reference in the git history. Considering versioning for content_builder is also a valuable aspect that we can address as we proceed with the release process with the current changes.
Build succeeded. https://ansible.softwarefactory-project.io/zuul/buildset/90aec0d225c74ff09565115872be29fc
:heavy_check_mark: ansible-test-cloud-integration-vmware-rest SUCCESS in 13m 28s :heavy_check_mark: build-ansible-collection SUCCESS in 12m 54s :heavy_check_mark: tox-cloud-refresh-examples-vmware SUCCESS in 11m 21s :heavy_check_mark: ansible-galaxy-importer SUCCESS in 4m 50s
Since there are three approvals: Is there any reason to not merge and release this?
/lgtm /approve
Build succeeded (gate pipeline). https://ansible.softwarefactory-project.io/zuul/buildset/63839650c5c34c3ca519bbaebcc2d6ec
:heavy_check_mark: ansible-test-cloud-integration-vmware-rest SUCCESS in 14m 40s :heavy_check_mark: build-ansible-collection SUCCESS in 11m 39s :heavy_check_mark: tox-cloud-refresh-examples-vmware SUCCESS in 10m 58s :heavy_check_mark: ansible-galaxy-importer SUCCESS in 5m 23s
Release 3.0.1