Paul Tagliamonte

Host Teams: Jason Shifflet, Jason Dengler, Mike Kovacina

I'm rather interested in creating a Constant integration server service. It should support testing and packaging (as well as some static checks)

#include <details.h> // ( I'm on my phone )

HOME

DWP Response: Topic sounds good. Need to see that header file to determine. I have some concerns about completion issues

AUGMENT and RESUBMIT

PRT: Update on topic / focus:

End product features:

- Run post-commit
- Build the source on the CIS
- Run test suites, if they exist
- Push code to a place that's useful — push to /var/www/, if a site, generate installable binary if actual local code.

Dependencies / assumptions:

- VCS will be git
- We have a way of "pushing" notifications, regardless of the git repo.

Milestones:
- M1: Post Commit, Build and Test
- M2: "Useful stuff" generation
- M3: Generic git support (ensure it's not tied to any codebase)
- M4: Verbose Email Reports

DWP response: APPROVED

Milestone Reports:
- M1:
Milestone 1 was hit with success. The paul-tagliamonte-code-dump page has the current state of the scripts.

The scripts checkout a clean copy of the code (always clean-room everything), merge in the build directory (debian/, to generate an installable .deb), generates the version number, and kicks off a build.

If all that was successful, it GPG signs the upload (with the server's key) and runs the upload routine to push the build out to the world.

Uploads can be found (for this Milestone) at the fluxbox-maintainers ppa.

The logs from the build can be found at the weather page.

DWP Response: 5/1/11
You got off to a good start, but there hasn't been any progress reports since the first one. Yes, I'm getting email updates (more than I should be), but that's not enough. I am okay with (and in fact encourage) students using outside projects for class, but doing so requires putting some effort into packaging the work to suit the needs of the class. Linking me to indecipherable pages designed for other team members related to the project does not fall into that category. I need *you* to decipher and explain to me what you are doing and why it is suitable for a final project in the class. I need you summarize what you have done and put it into a progress report so that I can attempt to ask reasonable questions. As of May 1, I really can't tell what, if any work you have put into this project since you added my e-mail to the distribution list. And, in what way, if any, that the work has been affected by being a final project for this class.

M4 Rundown

Milestones 2, 3 and 4 were hit on-time, a current snapshot of the code can be found at paul-tagliamonte-code-dump-m4.

The old script was ditched for the M2 rewrite, so that I could use a Makefile to allow a generic codebase to be used.

Basically, the makefile has a set of targets, and the CIS just runs the makefile hooks against the build directory. The current targets are:

clone

Get a copy of the codebase to use in the temp build-tree

clone-clean-integrate

Get any additional code needed for the clean-integration step (usually stuff for packaging)

echo-root

Get the name of the top-level build directory

test

Run the test suite

build

configure and build the codebase, this is a first cut try to see if it works in the testing (dirty) root.

dirty-integrate

If the build binaries are useful, we can save them or use it here. Most of the time this will be null.

clean-integrate

Prepare the codebase for a clean-room build, or actually do the build. Be sure the code base is pristine after this step

test-final-integration

Do a clean-room build for production use. This will *require* another build test. Most of the time, this will be done in a chroot to make sure the project dependencies have not changed.

migrate-integrations

Upload the cleanroom build to a build-farm. This will upload the source only, not the binary.

Rational

The code is tested 3 times, each in a slightly different way, so that issues can be traced to exactly what caused them, without doing any more builds locally. It also ensures that local dependencies do not touch the final integration binary.

This is also very generic, it allows any codebase (at all) to be built and integrated, regardless of what version control system they are using, language or build tools. Some of my output can be found at paul-tagliamonte-output

Deliverables

CID 1.0 Tarball
CID Overview