[LU-2763] Build: 1.8 git commit fails to allow long Test Paramters

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.4.0, Lustre 2.1.5, Lustre 1.8.9
• Type: Bug
• Priority: Minor
• Reporter: Keith Mannthey (Inactive)
• Assignee: Keith Mannthey (Inactive)
• Resolution: Not a Bug

Environment

The current Git Tree and Ubunut 12.04 desktop.

• Severity: 3

Description

I was trying to create a test patch with a meaningful Test-Paramaters.

The patch can be seen here http://review.whamcloud.com/5275

The paramaters in question are

Test-Parameters: nettypes=o2ib envdefinitions=SLOW=yes \
                 clientdistro=el6 serverdistro=el5 testlist=racer

The b1_8 build/commit-msg does not allow lines over 70 long. "\" escaping did not work does not work as it combines them together.

error: commit message has line longer than 70 columns.

The error message is seen regardless of the escaping used. I tired sever thing and in the end a used the "-r" change.

In the above patch I was able to work through the issue by adding a "-r" to the read command but is has been suggested that we bring back the entire commit-msg from current Master.

Comments

[Keith Mannthey (Inactive)]

http://review.whamcloud.com/5278 is the initial patch.

[Jian Yu]

Hi Keith,

We found that while editing commit message for a Lustre b2_1 patch with the following test parameters:

Test-Parameters: envdefinitions=DURATION=14400 \
clientdistro=el5 serverdistro=el5 clientarch=x86_64 \
serverarch=x86_64 clientcount=4 osscount=2 mdscount=2 \
austeroptions=-R failover=true useiscsi=true \
testlist=recovery-mds-scale

we got the following one after committing:

Test-Parameters: envdefinitions=DURATION=14400 clientdistro=el5 serverdistro=el5 clientarch=x86_64 serverarch=x86_64 clientcount=4 osscount=2 mdscount=2 austeroptions=-R failover=true useiscsi=true testlist=recovery-mds-scale

E.g., http://review.whamcloud.com/5462

On b1_8 branch, we can use two '\'s to escape '\', but this does not work on b2_1 and master branches.

[Keith Mannthey (Inactive)]

I find the double escape "
" an ok solution.

[Keith Mannthey (Inactive)]

There is a good workaround.