Squeak CI Job status
Locked
 
|
Hi Folks, Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing on the basis of being unable to use Git to checkout Frank's squeakci repository. I am not sure if that can be remedied by updating the installed software on the FreeBSD build slaves.I was taking a look at the build.squeak.org server and it seemed like there was a lot more red than green and I thought that I should at least start contributing to trying to fix that. I added a project a while back to show performance data from the image and it seemed to putting out some decent data, at least from a trendline perspective, for the last little while. Squeak was getting quite a bit faster from about the ~200 run of the project to #380 before it popped back up. I'll investigate the change in speed and see if I can figure out the regression. In the meantime however, the console output is showing that the actual tests ran fine, but the "bundle install" command is failing because we apparently don't have the appropriate ruby gem installed to run this command. Is this something I can fix via the Hudson web console or would I need access to the build server to do so? Does anyone with more ruby experience have a suggestion for this? Thanks for your help and time, Jeff |
|
|
On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote:
> Hi Folks, Hi Jeff, Thanks for looking into this, I think it is important to maintain this server and keep it producing meaningful tests. > > I was taking a look at the build.squeak.org server and it seemed like there > was a lot more red than green and I thought that I should at least start > contributing to trying to fix that. I added a project a while back to show > performance data from the image and it seemed to putting out some decent > data, at least from a trendline perspective, for the last little while. > Squeak was getting quite a bit faster from about the ~200 run of the > project to #380 before it popped back up. I'll investigate the change in > speed and see if I can figure out the regression. > > In the meantime however, the console output is showing that the actual > tests ran fine, but the "bundle install" command is failing because we > apparently don't have the appropriate ruby gem installed to run this > command. Is this something I can fix via the Hudson web console or would I > need access to the build server to do so? Does anyone with more ruby > experience have a suggestion for this? > > Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing on > the basis of being unable to use Git to checkout Frank's squeakci > repository. I am not sure if that can be remedied by updating the installed > software on the FreeBSD build slaves. The CogVM build job is maintained by me (independently of the actual Cog VM development). Is intended to verify code generation only, and the errors that you see there reflect an actual error in the code generation. Possibly the current error condition reflects some method that needs to be checked in to VMMaker for oscog. This is useful information, and the error messages in the workspace are real, so this is a good thing. The FreeBSD Interpreter job has never worked. It is apparently owned by nobody, and it seems to serve no useful purpose. I recall that it used to be failing due to an improperly configured slave server (a FreeBSD machine with duplicate and conflicting installations of UUID libraries I think) but now it fails for no reason that I can understand. If anyone feels any ownership for or interest in this job please speak up, otherwise I would be happy to have the job disabled. > > Finally I wanted to ask about build machine coverage. Do we still need a > mac osx build machine to use remotely with Hudson and what about a windows > machine? I have recently come into some machines and I was wondering if > donating time on those two operating systems would be worthwhile? They are > respectively running the latest version of OSX and Windows 8.1. I am > assuming that our linux coverage is good. I would think that test coverage for the Squeak unit tests on Windows and Mac OS X is very important indeed, and it would be great if you are able to provide that. Thanks, Dave > > Thanks for your help and time, > Jeff |
|
|
On 21 January 2014 00:58, David T. Lewis <[hidden email]> wrote:
> On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote: >> Hi Folks, > > Hi Jeff, > > Thanks for looking into this, I think it is important to maintain this > server and keep it producing meaningful tests. > >> >> I was taking a look at the build.squeak.org server and it seemed like there >> was a lot more red than green and I thought that I should at least start >> contributing to trying to fix that. I added a project a while back to show >> performance data from the image and it seemed to putting out some decent >> data, at least from a trendline perspective, for the last little while. >> Squeak was getting quite a bit faster from about the ~200 run of the >> project to #380 before it popped back up. I'll investigate the change in >> speed and see if I can figure out the regression. >> >> In the meantime however, the console output is showing that the actual >> tests ran fine, but the "bundle install" command is failing because we >> apparently don't have the appropriate ruby gem installed to run this >> command. Is this something I can fix via the Hudson web console or would I >> need access to the build server to do so? Does anyone with more ruby >> experience have a suggestion for this? It doesn't fail, it just warns about libyaml. And since we don't use any YAML stuff, I didn't bother "fixing" the problem. But I'm very happy that someone other than me actually reads the console output! Thanks! (The relevant warning is this: + bundle install /var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p392/lib/ruby/1.9.1/yaml.rb:56:in `<top (required)>': It seems your ruby installation is missing psych (for YAML output). To eliminate this warning, please install libyaml and reinstall your ruby. ) Oh. No, you're talking about SqueakTrunkPerformance. I missed that, in the sea of red :( That was just because the build wasn't configured to use rvm. Fixed, and apologies for not fixing sooner. >> Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing on >> the basis of being unable to use Git to checkout Frank's squeakci >> repository. I am not sure if that can be remedied by updating the installed >> software on the FreeBSD build slaves. See below. > The CogVM build job is maintained by me (independently of the actual Cog > VM development). Is intended to verify code generation only, and the errors > that you see there reflect an actual error in the code generation. Possibly > the current error condition reflects some method that needs to be checked in > to VMMaker for oscog. This is useful information, and the error messages in > the workspace are real, so this is a good thing. > > The FreeBSD Interpreter job has never worked. It is apparently owned by > nobody, and it seems to serve no useful purpose. I recall that it used to > be failing due to an improperly configured slave server (a FreeBSD machine > with duplicate and conflicting installations of UUID libraries I think) > but now it fails for no reason that I can understand. If anyone feels any > ownership for or interest in this job please speak up, otherwise I would > be happy to have the job disabled. All the FreeBSD jobs are owned by me :) They _do_ serve a useful purpose, which is to say "it doesn't work on FreeBSD". The machine on which those jobs run is being retired by its owner (I was but a guest), so until I find a new FreeBSD node (volunteers welcome! No, really!), I'll disable the jobs. I've already marked the sole node (havnor) as offline. >> Finally I wanted to ask about build machine coverage. Do we still need a >> mac osx build machine to use remotely with Hudson and what about a windows >> machine? I have recently come into some machines and I was wondering if >> donating time on those two operating systems would be worthwhile? They are >> respectively running the latest version of OSX and Windows 8.1. I am >> assuming that our linux coverage is good. I would love a Windows machine. LOVE. The current mac osx node (norst) runs, er, Snow Leopard, I think. It would be very useful to have a latest-and-greatest OSX because I don't plan on upgrading from Snow Leopard. > I would think that test coverage for the Squeak unit tests on Windows and > Mac OS X is very important indeed, and it would be great if you are able > to provide that. Test coverage is... _inadequate_, I think would be the polite way of putting it, both in the sense of our code having very low coverage, and in the sense of the tooling. TestCoverage tells you nothing more than that a method was run: there's no indication, for instance, that anything _inside_ that method ran. Also, you can't run coverage over anything in Kernel or a bunch of other places, because we always perform self-brain-surgery. frank > Thanks, > Dave > > >> >> Thanks for your help and time, >> Jeff |
|
|
Hi Folks,
On Tue, Jan 21, 2014 at 4:18 AM, Frank Shearar <[hidden email]> wrote:
Thank you for looking into this Frank. I will attempt to be more proactive about this job in the future and also get up to date on the latest configuration of the build server so that in the future I can take care of these issues myself. In the meantime your fix is greatly appreciated.
The mac machine is a stand alone machine and as long as apple lets me keep it up to date I will. For the windows machine I was thinking I would get it setup inside of a VM because I remember you mentioning something about having to give Hudson the ability to run remote jobs and that really this could allow it to pwn the machine if it were ever malicious. I figured a vm I just keep up and running would help mitigate some of this risk. Does this ring any alarm bells for you? If not, then I don't see any reason why I could not work to also get a FreeBSD vm up and running as well and then use that as the new machine. If I don't hear any warnings of dire consequences I will go about sanitizing the mac machine and getting the windows VM set up this weekend. I'll get to the FreeBSD machine later but I think promising all 3 for the weekend would be overly optimistic.
Thanks again for all of your feedback and hard work, Jeff |
|
|
On 21 January 2014 15:23, Jeff Gonis <[hidden email]> wrote:
> Hi Folks, > > On Tue, Jan 21, 2014 at 4:18 AM, Frank Shearar <[hidden email]> > wrote: >> >> On 21 January 2014 00:58, David T. Lewis <[hidden email]> wrote: >> > On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote: >> >> Hi Folks, >> > >> > Hi Jeff, >> > >> > Thanks for looking into this, I think it is important to maintain this >> > server and keep it producing meaningful tests. >> > >> >> >> >> I was taking a look at the build.squeak.org server and it seemed like >> >> there >> >> was a lot more red than green and I thought that I should at least >> >> start >> >> contributing to trying to fix that. I added a project a while back to >> >> show >> >> performance data from the image and it seemed to putting out some >> >> decent >> >> data, at least from a trendline perspective, for the last little while. >> >> Squeak was getting quite a bit faster from about the ~200 run of the >> >> project to #380 before it popped back up. I'll investigate the change >> >> in >> >> speed and see if I can figure out the regression. >> >> >> >> In the meantime however, the console output is showing that the actual >> >> tests ran fine, but the "bundle install" command is failing because we >> >> apparently don't have the appropriate ruby gem installed to run this >> >> command. Is this something I can fix via the Hudson web console or >> >> would I >> >> need access to the build server to do so? Does anyone with more ruby >> >> experience have a suggestion for this? >> >> It doesn't fail, it just warns about libyaml. And since we don't use >> any YAML stuff, I didn't bother "fixing" the problem. But I'm very >> happy that someone other than me actually reads the console output! >> Thanks! >> >> (The relevant warning is this: >> >> + bundle install >> /var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p392/lib/ruby/1.9.1/yaml.rb:56:in >> `<top (required)>': >> It seems your ruby installation is missing psych (for YAML output). >> To eliminate this warning, please install libyaml and reinstall your ruby. >> ) >> >> Oh. No, you're talking about SqueakTrunkPerformance. I missed that, in >> the sea of red :( That was just because the build wasn't configured to >> use rvm. Fixed, and apologies for not fixing sooner. >> > > Thank you for looking into this Frank. I will attempt to be more proactive > about this job in the future and also get up to date on the latest > configuration of the build server so that in the future I can take care of > these issues myself. In the meantime your fix is greatly appreciated. > >> >> >> Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing >> >> on >> >> the basis of being unable to use Git to checkout Frank's squeakci >> >> repository. I am not sure if that can be remedied by updating the >> >> installed >> >> software on the FreeBSD build slaves. >> >> See below. >> >> > The CogVM build job is maintained by me (independently of the actual Cog >> > VM development). Is intended to verify code generation only, and the >> > errors >> > that you see there reflect an actual error in the code generation. >> > Possibly >> > the current error condition reflects some method that needs to be >> > checked in >> > to VMMaker for oscog. This is useful information, and the error messages >> > in >> > the workspace are real, so this is a good thing. >> > >> > The FreeBSD Interpreter job has never worked. It is apparently owned by >> > nobody, and it seems to serve no useful purpose. I recall that it used >> > to >> > be failing due to an improperly configured slave server (a FreeBSD >> > machine >> > with duplicate and conflicting installations of UUID libraries I think) >> > but now it fails for no reason that I can understand. If anyone feels >> > any >> > ownership for or interest in this job please speak up, otherwise I would >> > be happy to have the job disabled. >> >> All the FreeBSD jobs are owned by me :) They _do_ serve a useful >> purpose, which is to say "it doesn't work on FreeBSD". The machine on >> which those jobs run is being retired by its owner (I was but a >> guest), so until I find a new FreeBSD node (volunteers welcome! No, >> really!), I'll disable the jobs. I've already marked the sole node >> (havnor) as offline. >> >> >> Finally I wanted to ask about build machine coverage. Do we still need >> >> a >> >> mac osx build machine to use remotely with Hudson and what about a >> >> windows >> >> machine? I have recently come into some machines and I was wondering >> >> if >> >> donating time on those two operating systems would be worthwhile? They >> >> are >> >> respectively running the latest version of OSX and Windows 8.1. I am >> >> assuming that our linux coverage is good. >> >> I would love a Windows machine. LOVE. The current mac osx node (norst) >> runs, er, Snow Leopard, I think. It would be very useful to have a >> latest-and-greatest OSX because I don't plan on upgrading from Snow >> Leopard. >> > The mac machine is a stand alone machine and as long as apple lets me keep > it up to date I will. For the windows machine I was thinking I would get it > setup inside of a VM because I remember you mentioning something about > having to give Hudson the ability to run remote jobs and that really this > could allow it to pwn the machine if it were ever malicious. I figured a vm > I just keep up and running would help mitigate some of this risk. Does this > ring any alarm bells for you? I think it's a very good idea to run the build slave as a VM for a couple of reasons: * Windows 8.1 ships with Hyper-V, so it's easy (he says not having tried it...) * If the VM is owned you can kill it without worrying about the host machine * Being in a VM makes it easier to keep the Jenkins stuff separate from your host machine > If not, then I don't see any reason why I could not work to also get a > FreeBSD vm up and running as well and then use that as the new machine. If you're up for it, I'd love to hear if you can get a FreeBSD VM running in Hyper-V. You certainly can in VirtualBox. > If I don't hear any warnings of dire consequences I will go about sanitizing > the mac machine and getting the windows VM set up this weekend. I'll get to > the FreeBSD machine later but I think promising all 3 for the weekend would > be overly optimistic. Great to hear! Thanks! frank >> > I would think that test coverage for the Squeak unit tests on Windows >> > and >> > Mac OS X is very important indeed, and it would be great if you are able >> > to provide that. >> >> Test coverage is... _inadequate_, I think would be the polite way of >> putting it, both in the sense of our code having very low coverage, >> and in the sense of the tooling. TestCoverage tells you nothing more >> than that a method was run: there's no indication, for instance, that >> anything _inside_ that method ran. Also, you can't run coverage over >> anything in Kernel or a bunch of other places, because we always >> perform self-brain-surgery. >> >> frank >> >> > Thanks, >> > Dave >> > >> > >> >> >> >> Thanks for your help and time, >> >> Jeff >> > > Thanks again for all of your feedback and hard work, > Jeff |
|
|
In reply to this post by Frank Shearar-3
On Tue, Jan 21, 2014 at 12:18 PM, Frank Shearar <[hidden email]> wrote:
I noticed a test failing on Windows. I posted a possible fix for it: Files-kfr.120 in the inbox. Cheers,
Karl The current mac osx node (norst) |
|
|
On Tue, Jan 21, 2014 at 09:57:11PM +0100, karl ramberg wrote:
> On Tue, Jan 21, 2014 at 12:18 PM, Frank Shearar <[hidden email]>wrote: > > > > > I would love a Windows machine. LOVE. > > > I noticed a test failing on Windows. > I posted a possible fix for it: > Files-kfr.120 in the inbox. Thanks Karl, I merged your fix into trunk, and moved Files-kfr.120 to the treated inbox. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |