Continuous Integration

[pedromorgan]

Maybe tidy5 could use some continuous integration to automate builds etc.

Options are

Tavis-ci.org

I submitted a patch here for travis integration, see notes at bottom
#173

Travis at its most basic, can check the code compiles

However, there are features, such as deploying articats, debs, zips to "somewhere"..

• see http://docs.travis-ci.com/user/deployment/

Of interest is github releases

• setup here http://docs.travis-ci.com/user/deployment/releases/
• and "binaries" would end up here https://github.com/htacg/tidy-html5/releases
• note releases only "releases" tags.

Jenkins

Am playing with a jenkins instance here on openshift.com

• https://jenkins-htacg.rhcloud.com/

And have already setup a "job" to compile the docs, and make a zip file as demoed here.

• https://jenkins-htacg.rhcloud.com/job/tidy-html5-linux-64-pedro-test/

For jenkins to work, we would need to setup some users, and also slaves.

Slaves can be anything, but we would need a linux32/64, windows32/64 mac etc..
and all the necessary software installed.

For jenkings access, please send me your email and requested username, so I can setup (cant thing of a better way)

[pedromorgan]

Releated Issues

• Remove build date support in favor of semantic versioning #148 Remove build date support in favor of semantic versioning
• Publish tidy-html5 to package managers #120 Publish tidy-html5 to package managers
• Build and install depency list #101 Build and install depency list
• Makefile missing uninstall #100 Makefile missing uninstall

[pedromorgan]

So it looks like I managed to get 64 bit deb/rpm packages on jenkins ;-)

https://jenkins-htacg.rhcloud.com/job/tidy-html5-linux-64/

[pedromorgan]

So this is an experimental build in my branch with the docs
https://jenkins-htacg.rhcloud.com/job/tidy-html5-linux-64-pedro-test/

[geoffmcl]

@pedromorgan thanks, now added to demo page http://www.htacg.org/binaries... starting to look GOOD ;=))

[balthisar]

@pedromorgan, What's the difference between Travis IC and Jenkins? Can you give us some very brief pros and cons for both of them? Do you have a preference, and why?

I'd like to avoid losing cohesiveness of the project, and would like to point people at a single CI solution rather than 20.

I was about the pull the Travis changes and enable it, but I'll wait for your feedback. We will defer to your expertise, but your decision will be final ;-)

[pedromorgan]

This sums up so diffs
http://thoughts.wallproductions.com/2014/01/jenkins-vs-travis/

both can compile and verify... it build

• travis is only 64 bit and linux (osx is expermental)
• Travis, integrates with gitgub seamlesly, eg tags can be releases
• jenkins need to be hosted, instance https://jenkins-htacg.rhcloud.com is on openshift free quota
• jenkisn does not compile on server, instead need slaves(nodes) and confis(sshkeys etc)
• jenkins can have windows, linux32, linux 64, osz slaves etc
• jenkisn is highly customisable and very flexible and can do most things in an aoutomated fashion

Using both is not considered harmful
a lot of foss project use travis just to check code
we can add jenkins to make the dist packages/ documentation, update website et all

[pedromorgan]

@balthisar maybe I send u jenkins login so u can play ? (gmail address right)

[geoffmcl]

@balthisar, @pedromorgan, as expressed to Pete directly I am against this... just do NOT see the need!

And to add to BOTH would be a complete folly. And it is not enough to reason that it does no harm.

A developer adding a fix has a responsibility to check for 'breakages' BEFORE commiting and pushing a change, and not depend on some remote build to show up an error, and thus require yet another fix.

Yes, we must do more work to make re-running the tests easier, and add more tests, but again it is the developer that should re-run such tests before commiting...

But as always, just a personal opinion.

[pedromorgan]

With osx slaves, linux32 and linux64 all running...

any developer who pushes a change would have it checked on all
possibilities..

The only reason I disovered a but with the man recently, is because I cos
an email from jenkins telling me build fail..

I missed it before, and so did jim, but a fresh checkout and a make
detected a culprit and was fixed...

Us developers miss things all the time..

On 8 March 2015 at 12:07, Geoff McLane [email protected] wrote:

@balthisar https://github.com/balthisar, @pedromorgan
https://github.com/pedromorgan, as expressed to Pete directly I am
against this... just do NOT see the need!

And to add to BOTH would be a complete folly. And it is not enough to
reason that it does no harm.

A developer adding a fix has a responsibility to check for 'breakages'
BEFORE commiting and pushing a change, and not depend on some remote build
to show up an error, and thus require yet another fix.

Yes, we must do more work to make re-running the tests easier, and add
more tests, but again it is the developer that should re-run such tests
before commiting...

But as always, just a personal opinion.

—
Reply to this email directly or view it on GitHub
#175 (comment).

[pedromorgan]

FOr fun I got the docs to autocompile on each push as proof of concept
http://tidy5docs-htacg.rhcloud.com/
eg mapped as
docs.html-tidy.org

[balthisar]

Since it seems so easy for developers to use any CI service of their choice, I wonder if it's best just to follow your lead and let developers use any CI service of their choice.

[pedromorgan]

I think you have completely miseed the point.. !! sign..

Gonna abandon this CO, most other projects have it or want it big time, and this project is back to olde style.

And all it is a simple configuratin and a free server...

I give up.. jenkins instance deleted...