Closed lb4368 closed 3 years ago
I can start working on this issue
Alternatively, instead of nightly updating the treasuremap pin ( 1. ), we could use the results of ( 2. ) as a release gate for publishing a new semantic version of airshipctl e.g. 2.0.6
. We can then pin to these patch versions explicitly, or we can pin to a minor e.g. 2.0 or major e.g.
2` version, as implemented in https://review.opendev.org/c/airship/airshipctl/+/762924/ which means we will not have to actually update the pin as it will move with new stable versions being published.
@seaneagan , Thanks for your suggestion to use the semantic version of airshipctl. The concern is, it is not just about uplifting treasuremap with airshipctl version, it should also be accompanied by the respective manifest changes in treasuremap to align with latest version of airshipctl. So the commit should have airshipctl version uplift together with the respective manifest changes in treasuremap. Only then zuul can use that combination and gate the changes. Please let me know if i did not explain well.
We have created a jenkins nightly job to validate the test-site of treasuremap using latest of treasuremap v2 with latest from airshipctl master.
Success: Confirms that the latest commit from airshipctl for validation is compatible with treasuremap v2 Failure: Latest changes of Airshipctl is not comaptabile with treasuremap v2 and it need further investigation to align treasuremap manifest with latest changes of airshipctl
We also have another Job to validate the treasuremap stability with commit locked version of airshipctl.
Success: Latest of treasuremap is stable Failure: Latest merges in treasuremap needs to be investigated for failure.
@lb4368 , can we mark this issue completed with the above pipelines working to validate the code stability of treasuremap v2 and treasuremap v2 compatibility with airshictl master
Closing per implementation above
Create a Treasuremap build to nightly pin airshipctl version to keep a stable working version of treasuremap.
Have we automated this yet? It's great that we have a job that's validating against the latest airshipctl builds, but if nothing is actually doing the pinning, the onus is on a developer to remember check the nightly builds and move this pin. In the case of success, it would be a lot easier to merge a gerrit change, like we had in Airship 1.
@drewwalters96 , Thanks for your feedback. I agree, for success scenario we can automate to push a gerrit commit with the airshipctl_ref uplifted in treasuremap.
I will try to implement that in the pipeline. If required will track that work with a new issue
Thanks @sirajyasin. I don't think it's something we need to solve today, but maybe after the release. In the case of an error, we could also file a GitHub issue so that someone can fix the incompatibilities.
Problem description Sometimes updates made in airshipctl can cause problems in treasuremap builds if corresponding updates are not made.
Proposed change 1) Create a Treasuremap build to nightly pin airshipctl version to keep a stable working version of treasuremap. 2) Create a gate to validate that its safe to update airshipctl.