The PKG_GITREVCOUNT would limit the scope of revisions to just the package dir, not the whole repo. In this case, however, I think they explicitly wanted to factor in changes to other packages in the same repo, and so the TIS_PATCH_VER component of the RPM version (used in the "release" component) is updated with any commit. There is a Launchpad to remove the hardcoded version reference from the playbook: https://bugs.launchpad.net/starlingx/+bug/1886742 -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Wednesday, July 15, 2020 11:26 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Updated Manifest repo for r/stx.4.0 - Please review & fire 4.0-rc build On 7/15/20 7:23 AM, Khalil, Ghada wrote:
Hi Saul, Not directly related, but have you seen/addressed the comments reported in https://review.opendev.org/#/c/740028/ ? I don't see an update to the cert-manager version in ansible in the r/stx.4.0 branch. I believe the bootstrap will fail if this is not adjusted.
I will admit I did not see this, I think in all honestly that should NOT have been merged and waited for a dependent patch for the playbook patch to merge. I am sorry I missed this, I saw that the patch merged, but did not notice the associated comment. I guess this is an unintended side-affect of the GITREVCOUNT change to TIS_PATCH_VER. I don't believe that the version should have changed for a branch and .gitreview addition (or for any non-code related change). This is the difference with PBR, the package version will change, but base version does not change. /me is very frustrated right now. Sau!
Thanks, Ghada
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Tuesday, July 14, 2020 4:09 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Updated Manifest repo for r/stx.4.0 - Please review & fire 4.0-rc build
On 7/14/20 12:26 PM, Saul Wold wrote:
On 7/14/20 10:26 AM, Khalil, Ghada wrote:
Hi Saul, Can you clarify the impact of this omission of the content of the r/stx.4.0 branch to date? Once the manifest is updated, will the commits that were being picked up from master (commits which merged after the July 8 1:30am build) in the stx.4.0 rc builds not be picked up anymore?
Not sure I understand what your asking, I don't think we offically opened the 4.0 branch. If anything has merged we should be able to determine based on what merged after all the .gitreview changes went in.
Nothing from master will be in the r/stx.4.0 branch unless explicitly cherry-picked.
BTW, the review below appears to be on the wrong branch. It should be on r/stx.4.0 not master.
OK, I found the root cause, PECAK [0]. Since I ended up creating the initial manifest r/stx.4.0 branch manually, I forgot to add the .gitreview change to update the .gitreview file. This then caused my update to fix the manifest to default to master by mistake. I have reverted the master change so that needs to be +2/+W. I have the .gitreivew pending once that is merged I can then merge my actual manifest fix for r/stx.4.0.
Thanks for the quick response on the revert and .gitreview, I have now posted the correct r/stx.4.0 manifest to the correct branch.
Sau!
I have already filed a story to make this part of the actual release scripts, so this should not be a problem in the future.
Sau!
[0] https://en.wiktionary.org/wiki/PEBCAK
Regards, Ghada
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Tuesday, July 14, 2020 9:50 AM To: starlingx-discuss@lists.starlingx.io; Little, Scott; Penney, Don; Panech, Davlet Subject: [Starlingx-discuss] Updated Manifest repo for r/stx.4.0 - Please review & fire 4.0-rc build
Scott, Davlet:
In the learning and doing of the branch/tag process last week, I missed updating the manifest repo correctly for the r/stx.4.0, that involved changing the default revision to use the r/stx.4.0 branch. This means that our current 4.0-rc is actually still building master and not the branched code.
Can you guys review [0] and when it merges re-fire the 4.0 builds (monolithic and layered).
I went back and reviewed the 2 sets of scripts, I had recalled after the fact that one set did handle creating a manifest, but when I reviewed it creates a hash based manifest which is not what we want either. So I believe we need a story to correctly create a manifest for both the branch and for when we create release tags for that branch which will be different. I have created a new story [1] for these tasks.
We should also choose 1 set of branching/tagging scripts so the next person that handles this can know which tools to use.
[0] https://review.opendev.org/#/c/740834/ [1] https://storyboard.openstack.org/#!/story/2007926
Sau!
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss