fcuny / jitterbug Goto Github PK

Figuring out from scratch is not fun

Don't make people press their back button.

on the page of the project, a graph representing the status of the build should be displayed.

a successful build is 1, a failed one is 0, and the status for the last 10 or 20 builds is graphed

It is not intuitive that the dates are links, they are the same color as all other text and not underlined.

These will be YAML config keys that specify programs to run before a build an after a build.

Shell quoting. Sigh.

Currently perlbrew fails to find the various perls that are installed by perlbrew and /usr/bin/perl is used in each test run.

Look at the TAP output on
http://sgn-build-64.sgn.cornell.edu:8090/project/testing

for b81142366c, "add .gitignore" to see the problem.

Each TAP output for each version of perl has a diagnostic line, and they are all actually /usr/bin/perl .

We will need at least three SQLite db files as test data : one which has no tasks (we already have this), one with one task added and one with a task that is currently being built.

It looks like t/004_project.t fails unless

perl -Ilib scripts/jitterbug_db --config t/data/test.yml --deploy

is run first. This should be automated in jitterbug::Test.

The command line arguments of 'mail' probably vary across OS's.

We need to have versions of config files, so we can change the config file format and migrate people.

Some people don't want perlbrew support, such as people who have test suites that take hours.

perlbrew can then become an optional dependency.

It would be awesome for the admin to be able to look at the jitterbug logs through the web to debug issues.

Yep.

Looks crappy

DBIx::Class::Relationship::CascadeActions::update(): No such column 'started_when' at lib/jitterbug/Builder.pm line 90

Re-cloning a repo for every test run uses a lot of network resources, and many people still pay for network transfer. For example, the non-profit biology lab that I work for is charged roughly $1/GB of network transfer by the university.

Instead of re-cloning each time, if the repo already exists, a "git pull --rebase" should be done. This should be an optional config key in config.yaml.

list all the pending builds in the dashboard

These headers/footers can contain useful info like a link to the Jitterbug web interface, etc..

It does everything we could want and more

Colors are pretty.

mail: invalid option -- -
usage: mail [-eIinv] [-a header] [-b bcc-addr] [-c cc-addr] [-s subject] to-addr ...
[-- sendmail-options ...]
mail [-eIiNnv] -f [name]
mail [-eIiNnv] [-u user]

remove a pending build

Allow the user to configure Jitterbug bug on a per-repo basis, i.e. the default will be the global Jitterbug default or what is set, but if the key is found in the per-repo section of the config file, that value will be used.

Yes, some PHP coders write tests, and we want them to use Jitterbug ;)

According to
http://www.phpunit.de/manual/current/en/organizing-tests.html#organizing-tests.filesystem

"If you point the PHPUnit command-line test runner to a directory it will look for *Test.php files."

and there is also an XML configuration file that can be used to specify tests

http://www.phpunit.de/manual/current/en/appendixes.configuration.html

What do people usually call the config file?

we have the date, the author that last touched it would be useful too

The email that is sent out has the commit message garbled.

For huge test outputs, the javascript to embed the output in the page times out. For an example, see

http://new.leto.net:3000/project/parrot

and click on the test output of "[cage] Remove some more svn-- remnants"

capsule.sh being in shell is blocking certain features, because capsule.sh does not know how to load our YAML config file.

This removes the dependency on cpanminus if Module::Build is being used.

These will be YAML config keys for programs to rub just before and just after a test run. These will be useful in case external processes need notification that a test run in starting/stopping. An example use of this would be to start a catalyst dev server before a test run and stop it afterwards.

Giving the total build time isn't very useful if you have many perls installed in perlbrew. An average time should be given if there are more than 1 perl installed.

DBIx::Class::Relationship::CascadeActions::update(): No such column 'started_when' at lib/jitterbug/Builder.pm line 90

Thought it was a warning, but the process dies just after this error.

name of project
build start and length
version of perl being used
commit msg and sha1

Currently we always link directly to the full output. A better solution would be to show a preview in a div and have a link to the full output. The preview needs to be smart enough to not timeout for big TAP streams, and should only show up to something around 500 lines of output, by default.

DBIx::Class::Relationship::CascadeActions::update(): No such column 'started_when' at lib/jitterbug/Builder.pm line 90

This was after running all of the scripts to upgrade from v1 to v4 of the schema.

In both the subject and body.

from the dashbord, you should be able to change the order of the pending builds

There should be an option to turn on the sending of PASS emails, with a similar mechanism that the FAIL emails have to specify a header and footer.

For really long TAP output, it would be really useful to have a list of failed files as a summary, at the top of TAP output.

the Build.PL should track dependence on App::perlbrew and Dist::Zilla

The user should be able to specify a custom test command, in case they don't want the autodetected one. This is useful if you have to create a special environment for your test suite to run.

Supporting the most common Node.js way of running tests would be nice. Who else?

Currently one can not side scroll in the TAP output