jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Continuum
  • CONTINUUM-565

Forced builds should say who (which continuum user) forced the build

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.4.0 (Beta)
  • Component/s: Core system
  • Labels:
    None
  • Complexity:
    Intermediate

Description

Currently if a build is forced the build history and notifications don't say who forced it. It would be nice if that was part of the history and notifications.

Issue Links

is duplicated by

New Feature - A new feature of the product, which has yet to be developed. CONTINUUM-1609 the user that forces a build should be included in the build result

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. CONTINUUM-1986 Store user id for forced builds

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

New Feature - A new feature of the product, which has yet to be developed. CONTINUUM-2265 Need information on who executed a release

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Wendy Smoak added a comment - 15/May/09 1:40 PM

Initial investigation

DefaultBuildController.java has method
public void build( int projectId, int buildDefinitionId, int trigger, ScmResult scmResult )

'build' is called from BuildProjectTaskExecutor.java:

    public void executeTask( Task task ) throws TaskExecutionException {
        BuildProjectTask buildProjectTask = (BuildProjectTask) task;
        controller.build( buildProjectTask.getProjectId(), buildProjectTask.getBuildDefinitionId(), buildProjectTask.getTrigger(), buildProjectTask.getScmResult() );
    }
  • 'trigger' is an integer, no additional info such as username is passed in
  • Brett suggested 'trigger' should be a class rather than an int
  • username needs to get into BuildProjectTask so it's available in BuildProjectTaskExecutor when calling controller.build

more in 20090514 #continuum irc log

Show
Wendy Smoak added a comment - 15/May/09 1:40 PM Initial investigation DefaultBuildController.java has method public void build( int projectId, int buildDefinitionId, int trigger, ScmResult scmResult ) 'build' is called from BuildProjectTaskExecutor.java:
    public void executeTask( Task task ) throws TaskExecutionException {
        BuildProjectTask buildProjectTask = (BuildProjectTask) task;
        controller.build( buildProjectTask.getProjectId(), buildProjectTask.getBuildDefinitionId(), buildProjectTask.getTrigger(), buildProjectTask.getScmResult() );
    }
  • 'trigger' is an integer, no additional info such as username is passed in
  • Brett suggested 'trigger' should be a class rather than an int
  • username needs to get into BuildProjectTask so it's available in BuildProjectTaskExecutor when calling controller.build
more in 20090514 #continuum irc log
Hide
Permalink
Wendy Smoak added a comment - 10/Jun/09 1:01 PM

This should be solved by CONTINUUM-2265 (Need information on who executed a build or release)

Show
Wendy Smoak added a comment - 10/Jun/09 1:01 PM This should be solved by CONTINUUM-2265 (Need information on who executed a build or release)
Hide
Permalink
Wendy Smoak added a comment - 15/Jun/09 8:57 AM

2009-05-14 irc conversation from my logs:

[4:56pm] wsmoak: does anyone know how anything actually gets built in Continuum?
[4:56pm] wsmoak: all I want to do is add "by <whoever>" on the build results page to show who forced a build
[4:57pm] brett: there's a build executor in core
[4:57pm] brett: you probably want to do a find usages on the add method of the build result dao
[4:57pm] wsmoak: BuildProjectTaskExecutor is one of the things I found
[4:58pm] brett: that's him
[4:58pm] wsmoak: all he does is call controller.build
[4:59pm] wsmoak: BuildController is an interface
[4:59pm] wsmoak: where's the code for pete's sake
[4:59pm] brett:
[4:59pm] wsmoak: there's no 'add' in the BuildResult class
[4:59pm] brett: BR, or BRDao?
[5:00pm] brett: if you're in eclipse, you can get an outline on the interface cass that shows subclasses
[5:01pm] wsmoak: just BR. hadn't found the Dao one.
[5:01pm] wsmoak: yeah, alt-F7
[5:02pm] wsmoak: DefaultBuildController. possibly.
[5:05pm] marica joined the chat room.
[5:07pm] wsmoak: looks like it would mean changing a method signature on DefaultBuildController.build.
[5:08pm] wsmoak: last time I tried something like that, it rippled through the entire app.
[5:09pm] brett: yah
[5:09pm] brett: it doesn't take a context of extra info?
[5:11pm] wsmoak: not afaict - public void build( int projectId, int buildDefinitionId, int trigger, ScmResult scmResult )
[5:12pm] brett: boo
[5:12pm] brett: trigger should be a class
[5:12pm] wsmoak: there's private void updateBuildResult( BuildContext context, String error ) that has a context...
[5:12pm] brett: might only be called on error
[5:14pm] wsmoak: darn. the build context gets created inside this class, it isn't passed in
[5:14pm] wsmoak: so... turn Trigger into a class and see what else has to change...
[5:14pm] brett: (everything)
[5:14pm] brett:
[5:15pm] wsmoak: yeah. here's the part where I decide changing stuff in continuum is way too hard and just go open more issues
[5:15pm] brett: I would probably overload it, not change it
[5:16pm] wsmoak: yeah. but I bet it's still going to be messy changing it on the other side where things are calling it.
[5:18pm] wsmoak: hm. we may be in luck... the only usage I can find is the aforementioned controller.build(...) in BuildProjectTaskExecutor
[5:19pm] wsmoak: which means BuildProjectTask has to change... and we'll leave figuring out who fills him up for another day
[5:22pm] wsmoak: thanks

Show
Wendy Smoak added a comment - 15/Jun/09 8:57 AM 2009-05-14 irc conversation from my logs: [4:56pm] wsmoak: does anyone know how anything actually gets built in Continuum? [4:56pm] wsmoak: all I want to do is add "by <whoever>" on the build results page to show who forced a build [4:57pm] brett: there's a build executor in core [4:57pm] brett: you probably want to do a find usages on the add method of the build result dao [4:57pm] wsmoak: BuildProjectTaskExecutor is one of the things I found [4:58pm] brett: that's him [4:58pm] wsmoak: all he does is call controller.build [4:59pm] wsmoak: BuildController is an interface [4:59pm] wsmoak: where's the code for pete's sake [4:59pm] brett: [4:59pm] wsmoak: there's no 'add' in the BuildResult class [4:59pm] brett: BR, or BRDao? [5:00pm] brett: if you're in eclipse, you can get an outline on the interface cass that shows subclasses [5:01pm] wsmoak: just BR. hadn't found the Dao one. [5:01pm] wsmoak: yeah, alt-F7 [5:02pm] wsmoak: DefaultBuildController. possibly. [5:05pm] marica joined the chat room. [5:07pm] wsmoak: looks like it would mean changing a method signature on DefaultBuildController.build. [5:08pm] wsmoak: last time I tried something like that, it rippled through the entire app. [5:09pm] brett: yah [5:09pm] brett: it doesn't take a context of extra info? [5:11pm] wsmoak: not afaict - public void build( int projectId, int buildDefinitionId, int trigger, ScmResult scmResult ) [5:12pm] brett: boo [5:12pm] brett: trigger should be a class [5:12pm] wsmoak: there's private void updateBuildResult( BuildContext context, String error ) that has a context... [5:12pm] brett: might only be called on error [5:14pm] wsmoak: darn. the build context gets created inside this class, it isn't passed in [5:14pm] wsmoak: so... turn Trigger into a class and see what else has to change... [5:14pm] brett: (everything) [5:14pm] brett: [5:15pm] wsmoak: yeah. here's the part where I decide changing stuff in continuum is way too hard and just go open more issues [5:15pm] brett: I would probably overload it, not change it [5:16pm] wsmoak: yeah. but I bet it's still going to be messy changing it on the other side where things are calling it. [5:18pm] wsmoak: hm. we may be in luck... the only usage I can find is the aforementioned controller.build(...) in BuildProjectTaskExecutor [5:19pm] wsmoak: which means BuildProjectTask has to change... and we'll leave figuring out who fills him up for another day [5:22pm] wsmoak: thanks
Hide
Permalink
Jevica Arianne B. Zurbano added a comment - 20/Jun/09 1:18 PM - edited

Fixed in:
r786863 in 1.3.x branch
r786876 in trunk

Show
Jevica Arianne B. Zurbano added a comment - 20/Jun/09 1:18 PM - edited Fixed in: r786863 in 1.3.x branch r786876 in trunk
Hide
Permalink
Wendy Smoak added a comment - 20/Jun/09 1:22 PM

When we were discussing this on the list I wasn't aware this was going on the 1.3.x branch, and the issue was marked for "1.x" so no clue there either. As a new feature/improvement, IMO it should have only gone on trunk.

Show
Wendy Smoak added a comment - 20/Jun/09 1:22 PM When we were discussing this on the list I wasn't aware this was going on the 1.3.x branch, and the issue was marked for "1.x" so no clue there either. As a new feature/improvement, IMO it should have only gone on trunk.
Hide
Permalink
Jevica Arianne B. Zurbano added a comment - 20/Jun/09 1:33 PM

Wendy, I have overlooked the fix for version, my mistake. Should I revert the commit in 1.3.x branch instead?

Show
Jevica Arianne B. Zurbano added a comment - 20/Jun/09 1:33 PM Wendy, I have overlooked the fix for version, my mistake. Should I revert the commit in 1.3.x branch instead?
Hide
Permalink
Jevica Arianne B. Zurbano added a comment - 20/Jun/09 2:35 PM

Reverted r786863 commit (r786891).

Show
Jevica Arianne B. Zurbano added a comment - 20/Jun/09 2:35 PM Reverted r786863 commit (r786891).
Hide
Permalink
Wendy Smoak added a comment - 20/Jun/09 8:29 PM

Well I wouldn't have insisted on reverting it since it was already done.

Thanks, though. I'm looking forward to seeing this in our first 1.4.x release!

I see you updated the unit tests already; I'll see if I can find the right place in the Selenium tests if no one beats me to it.

Show
Wendy Smoak added a comment - 20/Jun/09 8:29 PM Well I wouldn't have insisted on reverting it since it was already done. Thanks, though. I'm looking forward to seeing this in our first 1.4.x release! I see you updated the unit tests already; I'll see if I can find the right place in the Selenium tests if no one beats me to it.
Hide
Permalink
Wendy Smoak added a comment - 21/Jun/09 9:15 PM

do any docs (esp. screen shots) need to be updated for this?

Show
Wendy Smoak added a comment - 21/Jun/09 9:15 PM do any docs (esp. screen shots) need to be updated for this?
Hide
Permalink
Jevica Arianne B. Zurbano added a comment - 21/Jun/09 9:38 PM

Wendy, yes. The build result screen shot should be replaced to reflect the added field (Triggered by).

I will be updating the docs too.

Thanks!

Show
Jevica Arianne B. Zurbano added a comment - 21/Jun/09 9:38 PM Wendy, yes. The build result screen shot should be replaced to reflect the added field (Triggered by). I will be updating the docs too. Thanks!

People

  • Assignee:
    Jevica Arianne B. Zurbano
    Reporter:
    Jamie Flournoy
Vote (1)
Watch (1)

Dates

  • Created:
    19/Jan/06 1:07 PM
    Updated:
    21/Jun/09 9:38 PM
    Resolved:
    20/Jun/09 1:18 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.