Public Jenkins instance

[smo]

Hi everybody,

I've setup a Jenkins instance for ps3mediaserver: http://pms.smoeller.de/.

It's configured to execute continuous and nightly builds:

• continuous jobs: poll github once an hour for changes + execute "mvn clean package" if any new commits have been found
• nightly jobs: poll github once a day for changes + execute "mvn clean package site" if any new commits have been found

You want to use the latest builds for testing? See viewtopic.php?f=14&t=14753 for instructions. To get notified about new builds you can use RSS or follow the build server on twitter.

Feel free to request configuration changes for Jenkins! Any Jenkins plugins missing? Forks of pms that also should be built? Any other suggestions? Looking forward to get some feedback.

Regards,
smo

[chocolateboy]

Awesome! I was going to investigate setting this up on Travis. But I guess now I don't have to!

Any other suggestions?

Plugins?

[Raptor399]

Very nice, Smo!
I was about to do the same, thanks!

Nice to have the reports and the javadocs online now.

Any other suggestions?

Perhaps have Jenkins poll Git and build per commit, instead of twice per day?

[smo]

Awesome! I was going to investigate setting this up on Travis. But I guess now I don't have to!

Any other suggestions?

Plugins?

I'll look into it soon..

Any other suggestions?

Perhaps have Jenkins poll Git and build per commit, instead of twice per day?

Done.
Polling is done hourly to keep the load of the server at a reasonable level. However, please notice that during a build the response time for browsing the web gui isn't that good.

[taconaut]

Wasn't about to do the same, but having a nightly build executing tests, doing code analysis, generating the javadoc and what not is great! Thanks

[taconaut]

What about adding packaging goals to also create zips containing the windows and osx binaries? No need to create installers for people wanting to test nightly builds. This way people could easily test the current code, we just have to put up some visible links to it.

@smo
If you can host other forks, I'd love to see pms-mlx there too. Isn't space and bandwidth an issue?

[smo]

[...]
This way people could easily test the current code, we just have to put up some visible links to it.

Nightly builds for windows and osx sound like a nice idea. Maybe we should use 2 additional Jenkins jobs (1 for Windows, 1 for MacOs) that only checkout/compile/jar the current trunk (no unit testing, findbugs run...).
As I'm still new to maven, I'll need some support to configure the correct maven goals. Could you tell me the mvn command to generate the packages for windows and mac (without running the platform specific build tools)?

If you can host other forks, I'd love to see pms-mlx there too.

I've setup a job for pms-mlx but getting an build error. I can reproduce the problem on my local linux box.
I've temporarily increased the git polling time to every 15 minutes, so you should get results fast if you trying to fix the issue..

Isn't space and bandwidth an issue?

Space is not a problem at the moment. Builds older than 30 days are deleted by Jenkins. Do you think this is enough?

Bandwith isn't an issue for additional build jobs. However, I'm not sure how many user will download daily builds and generate traffic. But we can give it a try. As a fall back Jenkins could be configured to upload the nightly builds to another download site..

[taconaut]

[...]
This way people could easily test the current code, we just have to put up some visible links to it.

Nightly builds for windows and osx sound like a nice idea. Maybe we should use 2 additional Jenkins jobs (1 for Windows, 1 for MacOs) that only checkout/compile/jar the current trunk (no unit testing, findbugs run...).
As I'm still new to maven, I'll need some support to configure the correct maven goals. Could you tell me the mvn command to generate the packages for windows and mac (without running the platform specific build tools)?

I'm also new to maven, raptor is probably the one who knows the best how to do this. Without knowing if jenkins or maven is responsible, the process should ideally build pms.jar (with testing and so on; as it is now) which is the same for all platforms and only the packaging should differ to include the correct binaries for each build.

If you can host other forks, I'd love to see pms-mlx there too.

I've setup a job for pms-mlx but getting an build error. I can reproduce the problem on my local linux box.
I've temporarily increased the git polling time to every 15 minutes, so you should get results fast if you trying to fix the issue..

Thanks a lot for that! I've updated the problematic dependency and it is currently building

Isn't space and bandwidth an issue?

Space is not a problem at the moment. Builds older than 30 days are deleted by Jenkins. Do you think this is enough?

Bandwith isn't an issue for additional build jobs. However, I'm not sure how many user will download daily builds and generate traffic. But we can give it a try. As a fall back Jenkins could be configured to upload the nightly builds to another download site..

Cool, let's see how this evolves.

[Raptor399]

[...]
This way people could easily test the current code, we just have to put up some visible links to it.

Nightly builds for windows and osx sound like a nice idea. Maybe we should use 2 additional Jenkins jobs (1 for Windows, 1 for MacOs) that only checkout/compile/jar the current trunk (no unit testing, findbugs run...).
As I'm still new to maven, I'll need some support to configure the correct maven goals. Could you tell me the mvn command to generate the packages for windows and mac (without running the platform specific build tools)?

I'm also new to maven, raptor is probably the one who knows the best how to do this. Without knowing if jenkins or maven is responsible, the process should ideally build pms.jar (with testing and so on; as it is now) which is the same for all platforms and only the packaging should differ to include the correct binaries for each build.

The platform independent "pms.jar" is already created as a side effect of the Linux build, no need to do extra builds.
You can already download the file from the workspace/target directory.

[taconaut]

The benefit of having platform dependent packages would be to have the most recent binaries included besides the atpctal code