Last modified: 2012-11-14 12:15:31 UTC
Having to wait defeats the purpose, etc.
The auto merge can be handled in the gerrit hook "patchset-created" which is in operations/puppet.git : files/gerrit/hooks/patchset-created
Submitted this in Gerrit change #4020
Ok, we fixed and deployed this today. Attempted it for Gerrit change #4206, did not work. Logs from around the time of the push are included (probably a lot of noise)[0]. Possible causes to investigate: * Logic bug in hook * Lack of permissions for user to auto-merge (this is done as gerrit2, right?)
(In reply to comment #3) > * Lack of permissions for user to auto-merge (this is done as Gerrit change #2, right?) Silly auto-formatting. I meant that as the user gerrit[2]
(In reply to comment #3) > Ok, we fixed and deployed this today. Attempted it for Gerrit change #4206, did not > work. Logs from around the time of the push are included (probably a lot of > noise)[0]. > > Possible causes to investigate: > * Logic bug in hook > * Lack of permissions for user to auto-merge (this is done as Gerrit change #2, right?) Forgot the logs: http://p.defau.lt/?Xk0msgRkG9zibfacU40A2g
Will the change get merged even if the Jenkins build fail ? :-D
(In reply to comment #6) > Will the change get merged even if the Jenkins build fail ? :-D It should never fail. We have been doing these exports for years without much trouble.
I would prefer us to run the tests and merge automatically upon success. Just to be safe.
I would prefer to have this one fixed as soon as possible and improve it after that.
I *believe* fixed this last night. I forgot that the hook is running as gerrit[2] and the user lacked the rights to do the approve+submit. We can try again. Questions regarding whether or not to set verified or to wait for jenkins to do that can be discussed afterwords.
Chad, can you add the update I asked yesterday? The week is nearing its end and I am planning to start i18n commits next week, even if it means that somebody has to waste time clicking through all of the commits and chasing someone else to accept the ones he can't.
We fixed this today \o/ https://gerrit.wikimedia.org/r/#change,4804 Long story short, I should've debugged the options.uploader a week ago. A couple of minor things to adjust (like spam, etc) but those have their own bugs.
The actual fix is https://gerrit.wikimedia.org/r/4792 . The options.uploader is a user + email address field. 4804 prove the fix worked.
This broke again for an unknown reason last week. See <https://gerrit.wikimedia.org/r/#dashboard,137>. These all had to be accepted manually.
This should be fixed now since Gerrit change #8037 was merged. Will know for sure later today.
Don't care anymore. This does the trick and was added to the translatewiki.net repocommit script: for i in `ssh l10n-bot@gerrit.wikimedia.org -p 29418 gerrit query --format=TEXT owner:l10n-bot status:open |grep " url:" |cut -d/ -f5` do echo "Merging ${i}..." ssh l10n-bot@gerrit.wikimedia.org -p 29418 gerrit review $i,1 --code-review 2 --verified 1 --submit done
(In reply to comment #16) > Don't care anymore. This does the trick and was added to the translatewiki.net > repocommit script: > > for i in `ssh l10n-bot@gerrit.wikimedia.org -p 29418 gerrit query --format=TEXT > owner:l10n-bot status:open |grep " url:" |cut -d/ -f5` > do > echo "Merging ${i}..." > ssh l10n-bot@gerrit.wikimedia.org -p 29418 gerrit review $i,1 --code-review 2 > --verified 1 --submit > done For what it's worth, that's what I suggested Antoine do originally when he was overhauling the Translatewiki scripts--but he seemed to think doing it via a hook was better.
I still think it is better in the hook but I guess the command line is an acceptable workaround, even for long term :-] Good to see that long lasting issue finally solved !
Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116
