Automate AIRSHIPCTL_REF update

[lb4368]

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 Need Process to Keep airshipctl and treasuremap versions aligned #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]

@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]

@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]

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

[lb4368]

Thanks @sirajyasin

[seaneagan]

@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]

@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.