search

airshipit / treasuremap

Reference Airship manifests, CICD, and reference architecture.
http://openstack.org
Apache License 2.0
52 stars 39 forks source link

Automate AIRSHIPCTL_REF update #161

Open lb4368 opened 3 years ago

lb4368 commented 3 years ago

Problem description The process for updating the airshipctl commit reference (AIRSHIPCTL_REF) used for treasuremap gating still requires a manual validation and update. A pipeline was created as part of #100 to gate the latest airshipctl commit against the current treasuremap commit. We would like to have an more automated process use the result of the validation to update the AIRSHIPCTL_REF used by treasuremap upon a successful validation or create a notification to address a failed validation.

Proposed change

  1. Current validation job created as part of #100 validates the airship-core site type. This should be enhanced to also validate the multi-tenant site type.
  2. Upon successful validation, automatically push a patchset which updates the AIRSHIPCTL_REF with the validated airshipctl commit.
  3. Upon failed validation, create a notification (Github issue or something else) of the failure so interested parties will be aware of the failure and it can be addressed.
seaneagan commented 3 years ago

@lb4368 Do we need different validation for an AIRSHIPCTL_REF uplift than any other change? Why not just have the automation create the uplift patchset at the beginning which will trigger the gates like any other patchset. If there is an existing open "auto uplift" patchset, it can be updated with the new latest airshipctl tip reference, unless it has received code review or manual updates (can check its "uploader") in which case no action would be taken. If we want to create a new "auto uplift" patchset without merging the old one we could simply abandon the old one.

lb4368 commented 3 years ago

@seaneagan In the above scenario, where would the automation be? Would this be a nightly Jenkins job to create or update the current patchset or some other trigger based upon changes in airhsipctl? I am good with the doing the gating in a patchset because this would be a good mechanism for configuring success/failure notification.

sirajyasin commented 3 years ago

@lb4368 , I can start working on this issue if no one has started yet.

lb4368 commented 3 years ago

Thanks @sirajyasin

seaneagan commented 3 years ago

@lb4368 @sirajyasin It would be fastest if it could be triggered directly by airshipctl merges, but nightly should be ok too. Zuul should be able to support either triggering mechanism if we want to use it, otherwise third party CI should be fine too.

seaneagan commented 3 years ago

@sirajyasin If would be nice for the cases where it decided not to update the patchset due to manual updates or code review if it added a comment to the patchset saying that, along with the git SHA it was attempting to update to.

sirajyasin commented 3 years ago

Jenkins pipeline is created and it started pushing auto-uplift PSs to gerrit. Already 2 auto-uplift PSs created by jenkins CI are merged. https://review.opendev.org/c/airship/treasuremap/+/799113 https://review.opendev.org/c/airship/treasuremap/+/800091

Still there are some enhancements to be done like amending to a open auto-uplift PS instead of pushing new one and creating github issue on failure with logs attached.

sirajyasin commented 3 years ago

Auto uplift Pipeline is pushing PS upon successful build. However creating issue on failure is not addresses in this issue. As discussed, based on the priority any further enhancements to this uplift task will be created as a new issue and can be addressed on demand.

https://review.opendev.org/q/owner:airship2ci%2540gmail.com

@lb4368 ,Could we please mark this issue completed and we can open new issues in future on demand to address specific enhancement to uplift.