You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Leo Simons (JIRA)" <ge...@gump.apache.org> on 2005/03/28 00:31:31 UTC
[jira] Created: (GUMP-105) design a way to build against the last-successful-dependency-build
design a way to build against the last-successful-dependency-build
------------------------------------------------------------------
Key: GUMP-105
URL: http://issues.apache.org/jira/browse/GUMP-105
Project: Gump
Type: Task
Components: Python-based Gump
Versions: Gump3-beta
Reporter: Leo Simons
Fix For: Gump3-beta
The first algorithm to get right is GUMP-104, where we bail out of building at all if a dependency dies. The next step to tackle is to build against the last version of the dependency that /was/ built successfully.
This requires gump to become time-aware beyond a single build run, saving off previous successes into a repository and knowing about them. It requires a significant extension of the model where, for example
class BuildFailureRecoveryPlugin(AbstractPlugin):
visit_project(p):
if p.state <= FAILED:
successful_p = historyutil.lookup_last_successful_build(p)
modelutil.replace(p, succesful_p)
p.failed_project = p
p.state == RECOVERED
stages are inserted to keep most of the plugins blissfully unaware of the intelligence going on. If we get this right that'll be where the staged plugin model will really start to shine, as the graph theory people can design smart new algorithms (As long as they're compatible with the basic topsort we're doing in some way), and the build tool people can just, well, build stuff.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
[jira] Resolved: (GUMP-105) design a way to build against the last-successful-dependency-build
Posted by "Leo Simons (JIRA)" <ge...@gump.apache.org>.
[ http://issues.apache.org/jira/browse/GUMP-105?page=all ]
Leo Simons resolved GUMP-105:
-----------------------------
Resolution: Fixed
Implemented fully after SVN revision 333089. Still a very "experimental" feature but it seems to be holding up in basic testing. Good enough for now.
> design a way to build against the last-successful-dependency-build
> ------------------------------------------------------------------
>
> Key: GUMP-105
> URL: http://issues.apache.org/jira/browse/GUMP-105
> Project: Gump
> Type: Task
> Components: Python-based Gump
> Versions: Gump3-alpha-5
> Reporter: Leo Simons
> Assignee: Leo Simons
> Fix For: Gump3-alpha-5
>
> The first algorithm to get right is GUMP-104, where we bail out of building at all if a dependency dies. The next step to tackle is to build against the last version of the dependency that /was/ built successfully.
> This requires gump to become time-aware beyond a single build run, saving off previous successes into a repository and knowing about them. It requires a significant extension of the model where, for example
> class BuildFailureRecoveryPlugin(AbstractPlugin):
> visit_project(p):
> if p.state <= FAILED:
> successful_p = historyutil.lookup_last_successful_build(p)
> modelutil.replace(p, succesful_p)
> p.failed_project = p
> p.state == RECOVERED
> stages are inserted to keep most of the plugins blissfully unaware of the intelligence going on. If we get this right that'll be where the staged plugin model will really start to shine, as the graph theory people can design smart new algorithms (As long as they're compatible with the basic topsort we're doing in some way), and the build tool people can just, well, build stuff.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
[jira] Assigned: (GUMP-105) design a way to build against the last-successful-dependency-build
Posted by "Leo Simons (JIRA)" <ge...@gump.apache.org>.
[ http://issues.apache.org/jira/browse/GUMP-105?page=all ]
Leo Simons reassigned GUMP-105:
-------------------------------
Assign To: Leo Simons
> design a way to build against the last-successful-dependency-build
> ------------------------------------------------------------------
>
> Key: GUMP-105
> URL: http://issues.apache.org/jira/browse/GUMP-105
> Project: Gump
> Type: Task
> Components: Python-based Gump
> Versions: Gump3-alpha-5
> Reporter: Leo Simons
> Assignee: Leo Simons
> Fix For: Gump3-alpha-5
>
> The first algorithm to get right is GUMP-104, where we bail out of building at all if a dependency dies. The next step to tackle is to build against the last version of the dependency that /was/ built successfully.
> This requires gump to become time-aware beyond a single build run, saving off previous successes into a repository and knowing about them. It requires a significant extension of the model where, for example
> class BuildFailureRecoveryPlugin(AbstractPlugin):
> visit_project(p):
> if p.state <= FAILED:
> successful_p = historyutil.lookup_last_successful_build(p)
> modelutil.replace(p, succesful_p)
> p.failed_project = p
> p.state == RECOVERED
> stages are inserted to keep most of the plugins blissfully unaware of the intelligence going on. If we get this right that'll be where the staged plugin model will really start to shine, as the graph theory people can design smart new algorithms (As long as they're compatible with the basic topsort we're doing in some way), and the build tool people can just, well, build stuff.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
[jira] Commented: (GUMP-105) design a way to build against the last-successful-dependency-build
Posted by "Leo Simons (JIRA)" <ge...@gump.apache.org>.
[ http://issues.apache.org/jira/browse/GUMP-105?page=comments#action_12315232 ]
Leo Simons commented on GUMP-105:
---------------------------------
Work is underway to do this as part of
https://svn.apache.org/repos/asf/gump/branches/Gump3/pygump/python/gump/engine/persistence.py
and
https://svn.apache.org/repos/asf/gump/branches/Gump3/pygump/python/gump/engine/algorithm.py
it's turning out to be a hard problem :-)
> design a way to build against the last-successful-dependency-build
> ------------------------------------------------------------------
>
> Key: GUMP-105
> URL: http://issues.apache.org/jira/browse/GUMP-105
> Project: Gump
> Type: Task
> Components: Python-based Gump
> Versions: Gump3-alpha-5
> Reporter: Leo Simons
> Assignee: Leo Simons
> Fix For: Gump3-alpha-5
>
> The first algorithm to get right is GUMP-104, where we bail out of building at all if a dependency dies. The next step to tackle is to build against the last version of the dependency that /was/ built successfully.
> This requires gump to become time-aware beyond a single build run, saving off previous successes into a repository and knowing about them. It requires a significant extension of the model where, for example
> class BuildFailureRecoveryPlugin(AbstractPlugin):
> visit_project(p):
> if p.state <= FAILED:
> successful_p = historyutil.lookup_last_successful_build(p)
> modelutil.replace(p, succesful_p)
> p.failed_project = p
> p.state == RECOVERED
> stages are inserted to keep most of the plugins blissfully unaware of the intelligence going on. If we get this right that'll be where the staged plugin model will really start to shine, as the graph theory people can design smart new algorithms (As long as they're compatible with the basic topsort we're doing in some way), and the build tool people can just, well, build stuff.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org