https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-1476 Lustre <p>During the RC build for 2.1.2 the lustre version update was forgotten. There used to be code in configure which detected exactly such a mistake and broke the build because of it. It was put there for exactly this situation. c487014a39a6e37dc22a957aad9ad9b739e3c8cf was landed for <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a> which changed this error into a warning, of course, hiding the breakage.</p> <p>Indeed, it is always nice when manual processes (such as incrementing the bits for a new release) go off without a hitch, but having checks to make sure we do them all is probably even better.</p> <p>I'm still not convinced that the claims of the problems that were being made about that version/tag check in <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a> were all true but it seems a patch was landed anyway. That is, I'm not convinced that any old tag on a branch would cause configure to error out as was being claimed since the format of tags being looked at is pretty strict.</p> <p>I propose that the claims in <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a> be verified as either true or not and if found to be untrue, reverting c487014a39a6e37dc22a957aad9ad9b739e3c8cf so that we don't have this problem in the future.</p> <p>An alternative would be to add (yet) another switch to configure which toggles whether the checking code is to produce a warning or an error, defaulting to a warning. We could then add that switch to our jenkins build steps so that a tag/version mismatch produce a configure error for our builds causing the build to fail.</p> LU-1476

configure not enforcing tag == version

Bug Minor Resolved Low Priority WC Triage Brian Murrell Tue, 5 Jun 2012 07:23:42 +0000 Mon, 29 May 2017 03:59:06 +0000 Mon, 29 May 2017 03:59:06 +0000 0 2 <p>I hit the problem in <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a> several times, as did LLNL. The problem is when there is some other local tag that appears to be a valid tag, but doesn't exactly match the build version. The LLNL tag that failed was "2.0.59-1morrone", and the build version was 2.0.59:</p> <blockquote> <p>checking for buildid... configure: error: most recent tag found: 2.0.59-1morrone does not match current version 2.0.59</p></blockquote> <p>Since we already have special build rules for release versions (removing the git hash from the version string), it makes sense to special-case the "tag must match build version" rule as well, so that normal users are not affected by it.</p> <p>Looking at the source for that code the only tags that are considered for that check must match:</p> <p>ver=$(git describe --match v[<span class="error">&#91;0-9&#93;</span>]<em><b></em>[<span class="error">&#91;0-9&#93;</span>]</b> --tags)</p> <p>which is the m4 escaped regex "v<span class="error">&#91;0-9&#93;</span><em>*</em><span class="error">&#91;0-9&#93;</span>". So a tag of "2.0.59-1morrone" would not match. Neither would the "very_fine_patch" or "10_things_I_hate_about_autoconf" examples that were used in <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a>.</p> <p>The fix for that was landed in 3bf2ba3f3aa847e6d5ea9e0653e853aad0f4b95b specifically for <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a>.</p> <p>So as long as others didn't use that very specific tag format, they are safe.</p> <p>However, if we wanted to be even more flexible and allow the use that format with additional bits appended to it like the <a href="https://jira.whamcloud.com/browse/LU-278" title="Tag check is broken in configure script" class="issue-link" data-issue-key="LU-278"><del>LU-278</del></a> example: "2.0.59-1morrone" (which would not match any more so let's contort the example to something that would and call it "v2_0_59-1morrone") a simple patch to the existing code could truncate anything after our standard versioning tag format.</p> <p>Ultimately, I think the specific tag format that we look for now is narrow enough (and could even allow for appendages per above) that it doesn't seem unreasonable to reserve that format for our own use.</p> <blockquote> <p>Since we already have special build rules for release versions (removing the git hash from the version string), it makes sense to special-case the "tag must match build version" rule as well, so that normal users are not affected by it.</p></blockquote> <p>That special "release versions" code to remove the git hash is in fact all part and parcel of this code that we are discussing so there is really no "other" code that this tag/version comparison feature can become part of.</p> Development Rank 1|hzw3x3: Rank (Obsolete) 10729 Severity