Hooks fixed to treat trunk the same as master

Hooks fixed to treat trunk the same as master

[Joseph Myers]

Some time ago, someone added a git symbolic-ref for refs/heads/trunk 
pointing to refs/heads/master.

A side effect of this was to introduce a loophole in the checks run via 
commit hooks, some of which are configured to apply only to master and 
release branches and didn't apply if commits were pushed instead to trunk 
(this also meant that commits pushed to trunk didn't result in Bugzilla 
updates, and the emails to gcc-cvs didn't show the r12-NNNN short 
identifier for the commit).

In particular, the nightly DATESTAMP and ChangeLog updates have been 
broken for the past few nights because of a commit pushed to trunk with 
bad ChangeLog entries, which only got detected in the nightly cron job 
rather than at the time of the original push.

I've now changed the hooks to handle trunk the same as master (this mainly 
affects three of the hooks-bin scripts (commit_checker, 
commit_email_formatter, email-to-bugzilla-filtered), but I also updated 
refs/meta/config:project.config to ensure the rule blocking merge commits 
to master is properly applied to pushes to trunk as well).

Note that this doesn't fix the broken nightly updates; that will probably 
require some special-case handling of the broken commit message in the 
scripts; it just stops this particular cause of breakage from occurring in 
future.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Hooks fixed to treat trunk the same as master

[Martin Liška]

On 8/2/21 7:22 PM, Joseph Myers wrote:

Hey.

> Some time ago, someone added a git symbolic-ref for refs/heads/trunk
> pointing to refs/heads/master.

Great you found out what caused that. We were aware of commits that didn't
pass gcc-verify check but for some reason went in.

> 
> A side effect of this was to introduce a loophole in the checks run via
> commit hooks, some of which are configured to apply only to master and
> release branches and didn't apply if commits were pushed instead to trunk
> (this also meant that commits pushed to trunk didn't result in Bugzilla
> updates, and the emails to gcc-cvs didn't show the r12-NNNN short
> identifier for the commit).
> 
> In particular, the nightly DATESTAMP and ChangeLog updates have been
> broken for the past few nights because of a commit pushed to trunk with
> bad ChangeLog entries, which only got detected in the nightly cron job
> rather than at the time of the original push.

I'm going to fix that with Jakub. The problematic commit is from Aldy:
2e96b5f14e4025691b57d2301d71aa6092ed44bc:

git gcc-verify 2e96b5f14e4025691b57d2301d71aa6092ed44bc

Checking 2e96b5f14e4025691b57d2301d71aa6092ed44bc: FAILED

ERR: unchanged file mentioned in a ChangeLog: "gcc/Makefile.in"

ERR: unchanged file mentioned in a ChangeLog (did you mean "gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"?): "gcc/testsuite/dg.dg/analyzer/pr94851-2.c"

ERR: changed file not mentioned in a ChangeLog: "gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"


Aldy, can you please verify that you pushed the commit to 'trunk' branch name?

> 
> I've now changed the hooks to handle trunk the same as master (this mainly
> affects three of the hooks-bin scripts (commit_checker,
> commit_email_formatter, email-to-bugzilla-filtered), but I also updated
> refs/meta/config:project.config to ensure the rule blocking merge commits
> to master is properly applied to pushes to trunk as well).

Nods!

> 
> Note that this doesn't fix the broken nightly updates; that will probably
> require some special-case handling of the broken commit message in the
> scripts; it just stops this particular cause of breakage from occurring in
> future.
> 

I'm going to append Aldy's commit once 'Daily bump script' is run manually.

Thanks,
Martin

Re: Hooks fixed to treat trunk the same as master

[Aldy Hernandez]

On 8/3/21 9:33 AM, Martin Liška wrote:
> On 8/2/21 7:22 PM, Joseph Myers wrote:
> 
> Hey.
> 
>> Some time ago, someone added a git symbolic-ref for refs/heads/trunk
>> pointing to refs/heads/master.
> 
> Great you found out what caused that. We were aware of commits that didn't
> pass gcc-verify check but for some reason went in.
> 
>>
>> A side effect of this was to introduce a loophole in the checks run via
>> commit hooks, some of which are configured to apply only to master and
>> release branches and didn't apply if commits were pushed instead to trunk
>> (this also meant that commits pushed to trunk didn't result in Bugzilla
>> updates, and the emails to gcc-cvs didn't show the r12-NNNN short
>> identifier for the commit).
>>
>> In particular, the nightly DATESTAMP and ChangeLog updates have been
>> broken for the past few nights because of a commit pushed to trunk with
>> bad ChangeLog entries, which only got detected in the nightly cron job
>> rather than at the time of the original push.
> 
> I'm going to fix that with Jakub. The problematic commit is from Aldy:
> 2e96b5f14e4025691b57d2301d71aa6092ed44bc:
> 
> git gcc-verify 2e96b5f14e4025691b57d2301d71aa6092ed44bc
> 
> Checking 2e96b5f14e4025691b57d2301d71aa6092ed44bc: FAILED
> 
> ERR: unchanged file mentioned in a ChangeLog: "gcc/Makefile.in"
> 
> ERR: unchanged file mentioned in a ChangeLog (did you mean 
> "gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"?): 
> "gcc/testsuite/dg.dg/analyzer/pr94851-2.c"
> 
> ERR: changed file not mentioned in a ChangeLog: 
> "gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"
> 
> 
> Aldy, can you please verify that you pushed the commit to 'trunk' branch 
> name?

Sure, that sounds like me :).  I have some local branches based off of 
trunk.  For some reason I thought they were the same.

Sorry for the problems this has caused, and thanks for amending my commit.

I take it it's now ok to treat trunk and master the same?

Aldy

Re: Hooks fixed to treat trunk the same as master

[Martin Liška]

On 8/3/21 12:03 PM, Aldy Hernandez wrote:
> 
> 
> On 8/3/21 9:33 AM, Martin Liška wrote:
>> On 8/2/21 7:22 PM, Joseph Myers wrote:
>>
>> Hey.
>>
>>> Some time ago, someone added a git symbolic-ref for refs/heads/trunk
>>> pointing to refs/heads/master.
>>
>> Great you found out what caused that. We were aware of commits that didn't
>> pass gcc-verify check but for some reason went in.
>>
>>>
>>> A side effect of this was to introduce a loophole in the checks run via
>>> commit hooks, some of which are configured to apply only to master and
>>> release branches and didn't apply if commits were pushed instead to trunk
>>> (this also meant that commits pushed to trunk didn't result in Bugzilla
>>> updates, and the emails to gcc-cvs didn't show the r12-NNNN short
>>> identifier for the commit).
>>>
>>> In particular, the nightly DATESTAMP and ChangeLog updates have been
>>> broken for the past few nights because of a commit pushed to trunk with
>>> bad ChangeLog entries, which only got detected in the nightly cron job
>>> rather than at the time of the original push.
>>
>> I'm going to fix that with Jakub. The problematic commit is from Aldy:
>> 2e96b5f14e4025691b57d2301d71aa6092ed44bc:
>>
>> git gcc-verify 2e96b5f14e4025691b57d2301d71aa6092ed44bc
>>
>> Checking 2e96b5f14e4025691b57d2301d71aa6092ed44bc: FAILED
>>
>> ERR: unchanged file mentioned in a ChangeLog: "gcc/Makefile.in"
>>
>> ERR: unchanged file mentioned in a ChangeLog (did you mean "gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"?): "gcc/testsuite/dg.dg/analyzer/pr94851-2.c"
>>
>> ERR: changed file not mentioned in a ChangeLog: "gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"
>>
>>
>> Aldy, can you please verify that you pushed the commit to 'trunk' branch name?
> 
> Sure, that sounds like me :).  I have some local branches based off of trunk.  For some reason I thought they were the same.

All right.

> 
> Sorry for the problems this has caused, and thanks for amending my commit.

That happens, it's good knowing how the commits sneaked in.

> 
> I take it it's now ok to treat trunk and master the same?

Yes, that's how I understood the Joseph's email.

Martin

> 
> Aldy
> 

Re: Hooks fixed to treat trunk the same as master

[Joseph Myers]

On Tue, 3 Aug 2021, Martin Liška wrote:

> On 8/2/21 7:22 PM, Joseph Myers wrote:
> 
> Hey.
> 
> > Some time ago, someone added a git symbolic-ref for refs/heads/trunk
> > pointing to refs/heads/master.
> 
> Great you found out what caused that. We were aware of commits that didn't
> pass gcc-verify check but for some reason went in.

I think one of the previous such cases 
(c2be82058fb40f3ae891c68d185ff53e07f14f45) had a different cause, for 
which I've now filed <https://github.com/AdaCore/git-hooks/issues/20> 
after confirming I could reproduce that case.  (While 
04a040d907a83af54e0a98bdba5bfabc0ef4f700 was a case of a push to trunk.)

-- 
Joseph S. Myers
joseph@codesourcery.com