vulcan9 / vulcan Goto Github PK

In the build report, add field indicating why a build was performed:

* Changes found in repository
* New build of dependency "x"
* Forced by user

Pass BuildDetailCallback into RepositoryAdaptor.createWorkingCopy().
Add RepositoryAdaptor.updateWorkingCopy() to interface in case incremental
builds will be supported in the future.

The Subversion plugin supports tags and branches in the format

/foo/bar/projectName/trunk
/foo/bar/projectName/tags/1.1
...

It should also support the format
/trunk/projectName
/tags/1.1/projectName

In this case the tag name would still be "tags/1.1" but whatever comes
after the tag in the default case should be appended to the tag name.

Add a link to the build report which goes to the manual build form and
preselects the project.

Vulcan should calculate the elapsed time when a build executes and display
it on the detail page.

The build history report should offer an option to exlude ERROR or SKIP
outcomes since they may tend to skew the success rate statistics.

.NET plugin should allow user to choose between MSBuild or NAnt.

Extend the export capability to allow users to export only selected
configuration data such as:

o Projects
o Schedulers
o Builders
o Plugin Configs

When previous build exists and unit test metrics are recorded, detect
changes from one build to the next, including:

New Failures
Fixed Tests
New Tests
Deleted Tests (optional)

Allow authorized users to add free form comments to a build report.  Users
could use this feature to take responsibility for a broken build or give an
explanation for what went wrong, etc.

Admin users should be allowed to delete any comments.  Other users should
be allowed to edit or delete only their own comments.

The kill link is in a stupid location.  Add a "control" column to the build
daemon table and put the link there.  Possibly change the link to a button.
 Rename the text to "abort."

When a build does not pass, the details page shows the last known good
build timestamp and revision, but does not show the build number or link to
that build.  The code should be refactored to support this.

The tags mentioned in the subject do not work correctly when the client
does not submit an "Accept-Language" header, a commonplace use case when
rss or xml clients are in use.

This breaks rss.jsp and projects.jsp.

Admin user story for creating new project could be sped up dramatically by
allowing a user to copy an existing project to a new name.  The working
copy directory and project name are the only attributes that would be
required to change.

If a property is added to the ant configuration but no equals sign or value
is specified, the build fails with a cryptic error:

BUILD FAILED
Target `net.sourceforge.vulcan.ant.buildlistener.UdpBuildEventPublisher'
does not exist in this project.

SubversionRepositoryAdaptor.getLatestRevision (line 101) throws
NullPointerException when a path does not exist.  It should throw a more
informative exception.

After a user enters a project name, if the working copy is blank or matches
the template pattern, set the value to the template using the project name.

For example, if the user enter a project name "PetShop," populate the
working copy field with the value "/var/vulcan/projects/PetShop/sandbox."

Working copy should be validated to dissallow reserved locations such as
${vulcan.home}/projects/${project.name}.

If vulcan fails to load a build outcome during initialization, the entire
application fails to start.

Projects should be rebuilt when their configuration has been modified more
recently than the latest build.  They should also be rebuilt if related
plugin configuration has changed.

.NET plugin should allow configuration to specify global or project
specific properties to be passed into MSBuild or NAnt, similar to how the
ant plugin works.

The repository revision and tag name should be passed as properties.

The "Configuration" property should be a special case where the user can
select "Don't specify", "Debug", or "Release".

When tomcat does not have a chance to shutdown completely before the
process is killed, the config.xml file may be corrupted since it is in the
middle of writing the latest config.

Instead, write the new config to a temp file and rename it to the original
when done.  At the same time, if the contents have not changed, do not
overwrite the file.  This way the last modification time stamp will be
preserved.

Replace msbuild script with nant script which can be used in mono.

There is no intuitive way to disable a scheduler.  It can be done by
setting the interval to zero and erasing the cron expression.  There should
be an easier way.

When the project site file is not present, the file servlet should redirect
the user to the root of the project working copy.

Add framework for new type of plugin which can add custom metrics to
ProjectStatusDto.  Framework should allow a given plugin to access the
working copy to load metrics from xml files (such as unit test reports). 
Framework should also cause plugins to show report on build details page
such that e.g. unit test summary can be displayed with other details.

Non-numeric data in repository revision and repository label should be
stripped so the data can be used in versioning frameworks that require
numeric values.

Subversion revisions start with "r"; in this case the "r" should simply be
dropped.

The first time the Ant or Maven plugin start, the list of java homes will
be null.  When this is the case, add a new Java home using the system
property java.home.

This will simplify some design issues in each plugin, and allow the user to
delete the system profile if they wish to, or add max memory and system
properties to the profile.

If a project skips because a dependency fails, it should not report another
skip outcome when no changes have occurred.

Subversion plugin should count the number of files or bytes checked out and
cache the information.  The next time a project is being checked out, the
information can be used to compute an estimated progress percentage, which
can be displayed through the BuildDetailCallback.

An internal build number is already in use.  Modify vulcan to:

Increment build number
Supply build number to build tool plugin
Ant, Maven & MSBuild plugins should pass build number as property
Store build number in outcome
Show build number on build detail screen
Pass build number in build history report

In build details, find URLs and turn them into anchors.

In project config, allow specification of issue tracker url.  Translate
patterns like "bug 123", "bug #123" and "bug:123" into links to the issue
tracker.

A build outcome observer plugin which adds or modifies data in the
ProjectStatusDto should be executed before calling other build outcome
observer plugins which report the results through e-mail or other means.

Add a selector in the build history report which allows the user to choose
from:

* Build Outcome Report
* Commit Message Report

Add commit message report which shows table of commits (omitting changed
paths) and linkifies bugs and URLs.

The e-mail plugin has the following defects:

* Build number is always zero.
* Build Log and Diff links are incorrect.
* Issue list has no whitespace between ids (when css fails to work).
* Does not include images to round corners on tables.
* Add an optional reply-to header that is different from the sender address.

If vulcan is deploy to the root context in tomcat, the /manager URI for
manual builds in vulcan conflicts with the /manager application that is
bundled with tomcat.

Rename /manager to something else.  Probably should rename /admin too.

If a build log or diff is empty, don't offer a link to view it.

Change the maven plugin config to support specifying more than one maven
home.  Change the maven project config to allow user to choose which one to
use for each project.

This will allow vulcan to host projects that require different versions of
maven on the same instance.

After documentation is available, the screens should link into the relevant
section of help hosted on SourceForge.

If javac has errors, maven writes them to stderr which is discarded by vulcan.

Show build number in RSS and link to the build based on the build number. 
If feasible, show issues address in feed, and/or other relevant information.

When a build is running and a user looks at the build details, the page
should show whatever status is currently available, and periodically
refresh to fetch new data as it becomes available.

There seems to be a bug where building after a skip or error outcome, the
last-good-build-revision is used to obtain the change log.  This may cause
messages to appear in 2 builds since the changes may have been fetched for
a failed build after the last-good-build-revision.

Selection of multiple projects is broken.  Used to work.

Add the following user preferences (to be stored as cookies):

o Open external links in same window or new window
o When external window is already open, reuse it or open another window
o Select which projects to display on dashboard
o If more than one stylesheet is available, select stylesheet

Enhance the "Build requested by" information to indicate if the requester
is a scheduler or a user performing a manual build.

A client should be allowed to specify a request parameter which enables
vulcan to send simple text based information when enabled.  This would make
scripting integration with REST services such as the manual build action
more robust since they could easily detect errors

Project configuration should allow the user to check an option to prevent
the build details page from displaying warnings and errors emitted from the
build plugin.

Add an option to the build history report form which allows the user to
either view the report in the browser or download it.

If a project configuration for a given plugin requires access to the global
plugin configuration (e.g. svn global config defines many repositories; svn
project config allows you to select one), static globals are currently used
to share data between them.  This design sucks and should be fixed.

Extend import capability to allow merging partial config data into the
existing configuration.  When a project name or scheduler name is
duplicated, rename the project by adding "imported" or something to the name.

Options for conflict resolution:

When a project requires a plugin that is not present, either set the plugin
config to null or reject the import.

When plugin config data is present check to see if the data is equal to the
existing configuration.  If not, either:

o Reject the import
o Ignore the conflicting imported data
o Overwrite the existing data with the imported data