On 02 Jan 2014, at 12:25, Norbert Hartl <norb...@hartl.name> wrote: > > Am 02.01.2014 um 11:57 schrieb Esteban Lorenzano <esteba...@gmail.com>: > >> >> On 02 Jan 2014, at 11:49, Norbert Hartl <norb...@hartl.name> wrote: >> >>> >>> Am 01.01.2014 um 19:26 schrieb Esteban A. Maringolo <emaring...@gmail.com>: >>> >>>> Pharo as a community has support to use its CI server, among other >>>> goodies such as SmalltalkHub. >>>> >>>> But what if your code is not public and you want to have a central >>>> repository and continuous builds? >>>> >>>> Has anybody ever wrote a guide to develop with Pharo in the context of >>>> private development? >>>> >>>> So far I managed to work with a file based repo and a set of >>>> workspaces to create a new working image or to prepare it for >>>> deployment. But I want to automate it as much as I can. >>>> >>> I do what you want to do. I have a central server that I use for code >>> storage and for the CI builds. Have a look at [1]. There you can read how >>> you can easily create a http repository for monticello. I just create sub >>> directories for every project on my server and the rest just works. >>> The next step would be to install jenkins and add [2]. The jenkins server >>> then just uses the http repository you created before. >>> If you need help on this just ask. >> >> I use filetree and bitbucket for my private projects, and I use also >> metacello to build with them. > > I still didn’t find the time to look into filetree. It is yet another thing > to learn. Can you commit to bitbucket from within pharo? And I use metacello, > too, for building my projects.
is just another mc repository type, so no need to learn much. but you have a second step, because you do your “commits” to a local repository, then you do the actual commit/push using source tree or command line. Is a bit annoying, but well… at least all the authorisation stuff is made by others :) also, Thierry is doing gitfiletree so it will be better soon :) > >> if you do not want to use file tree format, you can use ftp or even dropbox >> :) > > That might raise some difficulties integrating that into a jenkins setup. And > to be honest I would avoid FTP where possible, there are other caveates with > it and it has no advantage over http. I worked with ftp without any problem. Anyway, it’s your choice :) > >> there is no need to make anything different on your private development than >> you do in your public ones. >> > It would be good if that would be the case. But all things that are public > accessible are not necessarily accessible in a private context. You chose > bitbucket which offers private repos. I chose to install my own WebDAV server > for mimicking the same. But that doesn’t work in all the contextes someone > might work in. like what? using filetree you delegate the authentication problems… so if you can reach the place from command line, you avoid the problem at zero cost. > >> ah, and scripts from Lukas are very outdated (I mean, a LOT). >> is a lot easier to take http://ci.inria.fr/pharo-contribution (any job >> there) as an example on how to configure a jenkins job in few lines. >> > Well, then I want to let you know that I’m using those scripts happily for > years. What do I get from upgrading? I don’t care about a few lines because I > have my workflow. Having the doubled amount of lines doesn’t make it worse. Maybe. People was using happily lots of things for years, yet things change. Improvement does not means always “old does not work”, sometimes is “newer is better”. New process is a lot simpler and does not require any external script… New process you just need to do: wget --quiet -O - get.pharo.org/30+vm | bash ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pier/Pier3/main ConfigurationOfPier3 --install=$VERSION --group=Tests ./pharo $JOB_NAME.image test --junit-xml-output "Pier.*" to install a configuration and run the tests… you cannot tell me that this is not an improvement, even if you already know how to use the older scripts. > > So I read his inquiry that he is willing to build his on stuff. The apache > config in my post is nearly a drop-in solution. Having that you just use > monticello as you (most likely) always did. Having an CI server on your own > machine (easy to install) gives you the control you need and you can skip > authorization settings between http repo and jenkins server which makes not > only building easier but also publishing results without having the need to > go over them and remove all sensible data. I would be glad if you would > describe a private development workflow in detail. Without that it is hard to > spot the drawbacks in your approach ;) > > Norbert > > >>> >>> Norbert >>> >>> [1] http://norbert.hartl.name/blog/2009/06/08/public-monticello-repository/ >>> [2] https://github.com/renggli/builder
