Hi all,
I've spend a bit of time writing a script that monitors gerrit and the git
repositories to update JIRA statuses. It's not quite done yet, but getting
there.
Basically it should be able to set the fixed version and close tasks
automatically.
Assuming there is no major protest, I'll use
On 7 Aug 2018, at 11:46, Frederik Gladhorn wrote:
>
> Hi all,
>
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
> Basically it should be able to set the fixed version and close ta
On Tue, 7 Aug 2018 11:46:12 +0200
Frederik Gladhorn wrote:
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
> Basically it should be able to set the fixed version and close tasks
>
>
>From: Development on
>behalf of Frederik Gladhorn
>Sent: Tuesday, August 7, 2018 12:46 PM
>To: development@qt-project.org
>Subject: [Development] Closing issues automatically with new keyword
>
>Hi all,
>
>I've spend
> -Original Message-
> From: Development project.org> On Behalf Of Jani Heikkinen
> >The plan is to update the fix versions and close the task as done when
> >a line in the commit message starts with "Fixes:".
> >If the issue is already closed (e.g. cherry-pick) it can add an
> >additiona
On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
>
so why exactly are you doing this after i implied in
https://bug
Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:
Hi all,
I've spend a bit of time writing a script that monitors gerrit and the git
repositories to update JIRA statuses. It's not quite done yet, but getting
there.
Basically it should be able to set the fixed version and close tasks
automaticall
On tirsdag 7. august 2018 15.23.52 CEST Robert Löhning wrote:
> Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:
> > Hi all,
> >
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > th
> On 7 Aug 2018, at 16:06, Frederik Gladhorn wrote:
>
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
>> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
>>> I've spend a bit of time writing a script that monitors gerrit and the git
>>> repositories to upda
On Tuesday, 7 August 2018 04:59:02 PDT Jani Heikkinen wrote:
> I see at least one problem there: If bug is affecting to several branches it
> will be closed when fix for first branch is done even in that case it
> shouldn't be closed until every branch has a fix...
I usually close the bug when the
On Tuesday, 7 August 2018 02:46:12 PDT Frederik Gladhorn wrote:
> The plan is to update the fix versions and close the task as done when a
> line in the commit message starts with "Fixes:".
Thanks, Frederik!
Please update the changelog-creation script to detect this keyword too.
--
Thiago Macie
On Tue, Aug 07, 2018 at 04:06:38PM +0200, Frederik Gladhorn wrote:
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> > did your investigation reveal that it's unsalvagably bad?
>
> I guess it could work
On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> > -Original Message-
> > From: Development > project.org> On Behalf Of Jani Heikkinen
> >
> > >The plan is to update the fix versions and close the task as done when
> > >a line in the commit message starts with "Fixes:".
> > >
Hi Frederik,
one more question: does the script also sets the final Git-SHA1 in the
Jira "commits" field?
If yes, that would really be a *big* improvement.
> Everything else (wip/foobar, other branch names) will be ignored,
> unless someone explains what to do with them otherwise.
I think th
On onsdag 8. august 2018 12.13.46 CEST André Hartmann wrote:
> Hi Frederik,
>
> one more question: does the script also sets the final Git-SHA1 in the
> Jira "commits" field?
>
> If yes, that would really be a *big* improvement.
Yes, that's the plan.
Frederik
>
> > Everything else (wip/foob
On Wednesday, 8 August 2018 02:58:08 PDT Frederik Gladhorn wrote:
> branch is x.y -> find the next valid patch version
Suggestion: use the x.y release and when we make that release, we rename it in
JIRA.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Sourc
From: Development
on behalf of Thiago Macieira
>Suggestion: use the x.y release and when we make that release, we rename it in
>JIRA.
That is the current approach and it does not work or scale. Between branching
time and release time is a fairly long
On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> That is the current approach and it does not work or scale. Between
> branching time and release time is a fairly long time. By then the x.y
> branch contains already x.y.(z+1) fixes (assuming the latest release branch
> is x.y.z). It i
From: Development
on behalf of Thiago Macieira
On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> That is the current approach and it does not work or scale. Between
> branching time and release time is a fairly long time. By then the x.y
>
On Fri, Aug 10, 2018 at 08:38:46AM +, Alexander Blasche wrote:
> Thiago Macieira wrote:
> > On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> > > That is the current approach and it does not work or scale.
> > > Between branching time and release time is a fairly long time. By
> >
> On 10 Aug 2018, at 12:07, Oswald Buddenhagen wrote:
>
> so now i think the hook/intergration should just set the fix version to
> the target branch name. yes, that implies that we should have the
> version "dev" in jira.
Why? I think you can check the tags in git and find out that the highes
On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 12:07, Oswald Buddenhagen wrote:
> > so now i think the hook/intergration should just set the fix version to
> > the target branch name. yes, that implies that we should have the
> > version "dev" in jira.
>
> Wh
> On 10 Aug 2018, at 15:14, Oswald Buddenhagen wrote:
>
> On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
>> On 10 Aug 2018, at 12:07, Oswald Buddenhagen
>> wrote:
>>> so now i think the hook/intergration should just set the fix version to
>>> the target branch name. yes, that
On Fri, Aug 10, 2018 at 03:57:31PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 15:14, Oswald Buddenhagen wrote:
> > secondly, as your own caveat highlights, you need to encode and
> > maintain policy in the script to make that work.
>
> Starting to use the Fixes: tag at all is a policy, and
Quick status update from my side:
I have the script running against a test installation of JIRA. It seems to
work, there are some small issues to be worked out still.
- Qt Creator version numbers are verbose, so I need to be more generous in
matching strings, right now I don't detect the version
Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
> Quick status update from my side:
> I have the script running against a test installation of JIRA. It seems to
> work, there are some small issues to be worked out still.
>
> - Qt Creator version numbers are verbose, so I need to be more generou
> On 29 Aug 2018, at 20:17, Robert Löhning wrote:
>
> Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
>> Quick status update from my side:
>> I have the script running against a test installation of JIRA. It seems to
>> work, there are some small issues to be worked out still.
>>
>> - Qt Cre
On onsdag 29. august 2018 20.17.52 CEST Robert Löhning wrote:
> Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
> > Quick status update from my side:
> > I have the script running against a test installation of JIRA. It seems to
> > work, there are some small issues to be worked out still.
> >
>
Quick update:
Sanity bot and commit template (in 5.11, soon other places) are now updated
and the bot is running.
I'd appreciate if people tried using the Fixes: footer and let me know if the
issue is closed with the right version (or even better, if the fix version is
not set or incorrectly se
On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> One thing that would still be great to have is the jira links working so
> that the changes show up in JIRA like they do for Task-number, I'm looking
> into this and thought the config was fixed, but so far that doesn't seem
I committed this to 5.11 branch:
https://codereview.qt-project.org/#/c/240566/
Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
https://bugreports.qt.io/browse/QTBUG-70493
I'm not sure if it should automatically select the next unreleased version
(5.11.3) or use more general
On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
> I committed this to 5.11 branch:
> https://codereview.qt-project.org/#/c/240566/
>
> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
> https://bugreports.qt.io/browse/QTBUG-70493
>
> I'm not sure if it sh
> I looked into the code... That happened because none of these commands
> returned 5.11.x:
> git show-ref --tags
> git show-ref --heads
> So from the bot perspective 5.11 branch was never released therefore 5.11.0 is
> the next release. For me it looks quite sane, who can add missing tags?
Than
> On 21 Sep 2018, at 12:47, Jedrzej Nowacki wrote:
>
> On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
>> I committed this to 5.11 branch:
>> https://codereview.qt-project.org/#/c/240566/
>>
>> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
>> https:
On Friday, September 21, 2018 1:02:10 PM CEST Tor Arne Vestbø wrote:
> > On 21 Sep 2018, at 12:47, Jedrzej Nowacki wrote:
> >
> > On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
> >
> >> I committed this to 5.11 branch:
> >> https://codereview.qt-project.org/#/c/240566/
> >
> On 21 Sep 2018, at 13:32, Jedrzej Nowacki wrote:
>>
>> Shouldn’t that pick refs/heads/5.11?
>>
>> Tor Arne
>
> Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
> therefore it marked 5.11.0 as fixed version.
That doesn’t make any sense. The 5.11 branch is constantly
On 21.09.2018 15:32, Tor Arne Vestbø wrote:
On 21 Sep 2018, at 13:32, Jedrzej Nowacki wrote:
Shouldn’t that pick refs/heads/5.11?
Tor Arne
Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
therefore it marked 5.11.0 as fixed version.
That doesn’t make any sense.
Hi,
I get this warning when I only add 'Fixes:' in the footer:
***
*** Suspicious changes in commit HEAD (QSqlQuery: add another testcase
for bindBool()):
***
*** commit message:
*** - 8: Text following footers (key "footer")
***
*** See http://wiki.qt.io/Early_Warning_System for expla
Am 23.09.2018 um 17:39 schrieb Christian Ehrlicher:
Hi,
I get this warning when I only add 'Fixes:' in the footer:
***
*** Suspicious changes in commit HEAD (QSqlQuery: add another testcase
for bindBool()):
***
*** commit message:
*** - 8: Text following footers (key "footer")
***
***
Hello again,
After another round of fixing (such as allowing to close issues that are 'In
Progress', because they have a different name for the transition), adding the
setting of the commit sha1 and no longer setting too many versions, we should
be live with a working bot.
I'm interested in is
41 matches
Mail list logo