IRC logs for #baserock for Friday, 2017-07-14

« Thursday, 2017-07-13 Index Saturday, 2017-07-15 »
*** locallycompact has joined #baserock06:09
*** locallycompact has quit IRC06:12
*** locallycompact has joined #baserock06:13
*** locallycompact has quit IRC06:14
*** rdale has joined #baserock07:41
*** jonathanmaw has joined #baserock07:51
*** jonathanmaw has quit IRC08:03
*** jonathanmaw has joined #baserock08:04
*** gtristan has joined #baserock08:04
*** toscalix has joined #baserock08:09
*** bruce has joined #baserock08:12
*** bruce is now known as Guest5525408:12
*** Guest55254 has quit IRC08:14
*** ctbruce has joined #baserock08:14
benbrown_ironfoot: :)08:20
ironfoothm... I'm curious about this failure: https://gitlab.com/baserock/definitions/-/jobs/2239928408:44
ironfootcaused by $TARGET being now $(gcc -dumpmachine), and not working for core/libffi08:45
*** ssam2 has joined #baserock09:13
*** ChanServ sets mode: +v ssam209:13
gitlab-br-botinfrastructure: merge request (sam/cleanup->master: Clean up some unused infrastructure definitions) #4 changed state ("closed"): https://gitlab.com/baserock/infrastructure/merge_requests/409:22
gitlab-br-botdefinitions: merge request (tristan/bst_colors->jjardon/bst_test: .gitlab-ci.yml: Enable colors on the CI) #45 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/4509:27
gtristanjjardon, because I find it so obnoxious... https://gitlab.com/baserock/definitions/merge_requests/45 :)09:27
ssam2it's pretty annoying that the CI takes 4 1/2 minutes pulling the Docker image09:30
ssam2I got really excited about my build possibly working for the first time and then it failed because I spelled '--colours' with a u09:30
benbrown_:D09:34
ironfoottsk!09:35
paulsher1oodlol09:48
ironfootI've noticed that gitlab workers install packages needed very very very quick09:49
ironfootthey might some caching in place for them, so that you don't endup downloading them all the time09:50
ssam2is there a way to embed config file snippets in .gitlab-ci.yml ? my initial attempt has failed spectacularly09:51
ssam2https://gitlab.com/baserock/definitions/-/jobs/2248004009:51
ssam2that's the result of https://gitlab.com/baserock/definitions/blob/81f8edacfddf595101b158bc2da37e6a9f1dc584/.gitlab-ci.yml#L4009:51
ironfoot.... "echo"... ??!?!?!09:54
ssam2yeah wtf09:54
ssam2I guess I could try echoing each line of my config individually09:54
ironfootyeah, that could work, but this error is...09:55
ironfootwow09:55
ssam2but finally... a build on gitlab CI using the artifact cache ! https://gitlab.com/baserock/definitions/-/jobs/2248102410:02
gtristanhttps://gitlab.com/baserock/definitions/-/jobs/22478435 ... looks like the cache needs to be setup10:03
gtristanunless you want to download all the sources every time10:03
gtristanbut that's just a fork of jjardon's test so probably unfinished, anyway we setup a source cache for buildstream's CI10:04
ssam2jjardon's and my work is separate so far10:05
gtristanyeah10:05
ssam2local caching is apparently difficult to do with the way the current runners are set up10:05
ssam2yeah it sucks that we have to download sources each time10:05
ssam2but I think we have to set up an S3 bucket or something if we want those runners to have a cache10:06
gtristanssam2, you also need the cache :)10:06
gtristanssam2, look at buildstream-tests repo for some prior art, I dont personally know how it works, tlater would10:06
ssam2those use the default gitlab-ci runners, which can have a cache easily10:06
ssam2the Baserock runners are transient on-demand thingies and so it's much harder10:06
ssam2that's my understanding of the problem10:07
ssam2but the default runners are slow, that's why we don't use them10:07
gtristanright10:07
jjardonssam2: you are rigth10:07
jjardonwe need https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/autoscaling.md#install-the-cache-server or similar10:08
jjardonssam2: I hope we are not duplicating work here?10:08
ssam2jjardon: me too :-)10:09
jjardonI'm basically try to fo the first point from https://gitlab.com/baserock/definitions/issues/1110:09
ssam2right10:09
jjardonso having a pipeline that convert to buildstream a and build the same in ybd and bst10:10
ssam2I'll leave you to it :-)10:10
ssam2i just need a local conversion of things for now, which I already have10:10
ssam2i'm going to clean it up a bit and document it10:10
jjardonah, ok; different then :)10:11
ssam2but we will hit the same issues, so be sure to keep an eye on my branch10:11
jjardonI will try to cherry pick from your branch so maybe I can fix the problem Im currently hitting with libffi10:11
jjardonsure, thanks10:11
ssam2you can start using the cache server too10:12
ssam2the only catch is you have to be on a protected branch to be able to access the ssh private key10:13
jjardongtristan: you know I will not be able to merge that branch, rigth? :)10:13
jjardonI will cherry pick instead, thanks for the patch!10:13
gtristanjjardon, I dont know that you will not be able to merge it, actually10:14
gtristanjjardon, but do how you like :)10:14
jjardongtristan: its a dev branch: it doesnt even compile now, so the CI will not pass10:14
gtristanjjardon, how does CI not passing prevent you from merging ?10:15
jjardonIts how the project is configured10:16
gtristanin any case, cherry pick, or whichever :)10:16
jjardonCI needs to pass10:16
gtristanoh, you mean if you like to use fancy buttons on a web page10:16
gtristanthat is another story10:16
jjardongtristan: you used the fancy UI for your MR10:17
SotKgating on CI passing is the most sensible way to configure a project :)10:17
jjardonno one can push to master though, It has to go through the MR process10:18
gitlab-br-botdefinitions: merge request (tristan/bst_colors->jjardon/bst_test: .gitlab-ci.yml: Enable colors on the CI) #45 changed state ("closed"): https://gitlab.com/baserock/definitions/merge_requests/4510:18
*** locallycompact has joined #baserock10:21
*** locallycompact has quit IRC10:27
*** locallycompact has joined #baserock10:28
ssam2it does seem like baserock.org infra has just died10:30
ssam2I can't ping naything10:30
ssam2http://status.datacentred.io/ suggests no issues though10:32
ssam2ok, the frontend machine was turned off10:34
ssam2wtf10:34
ironfootI think VMs have a log for that10:34
ssam2req-830de377-d9a9-49c9-a23f-3ef8597667eb Stop July 14, 2017, 3:08 a.m. -10:34
ssam2indeed it does, but there's not much useful info :-)10:34
ironfootthere is an user id10:35
ssam2there is for other entries, but not for this one10:35
ironfootah no10:35
ironfootthen, it wasn't done clicking horizon buttons10:36
ironfootbut something like a `poweroff` in the vm itself10:36
ironfootat 04:08 .. :S10:37
ssam2yeah10:37
* ironfoot goes to see the journal10:38
ssam2all I see is `dnf makecache`10:39
ssam2maybe that ruined things for us10:39
ssam2i don't get why it won't respond to ping anymore either ...10:41
ironfoot"ping" needed some extra rules, I don't know if the firewall has them in place10:42
ssam2i just checked, it does10:42
ironfootodd :S10:43
jjardonssam2:  only curious, where did you setup the cache server? digitalocean?10:53
ssam2datacentred10:54
paulsher1oodbenbrown_: https://gitlab.com/baserock/ybd/pipelines/9820997 ?10:58
benbrown_one for jjardon I think10:59
benbrown_all report lack of disk space10:59
benbrown_nothing to do with the changes merged11:01
gitlab-br-botybd: merge request (jjardon/cache_location->master: .gitlab-ci.yml: Use /cache to put all contents) #373 changed state ("opened"): https://gitlab.com/baserock/ybd/merge_requests/37311:02
jjardonbenbrown_:  that should fix it11:03
ssam2is there a browser that can view long logs on gitlab CI without requiring 100% CPU ?11:04
ssam2firefox is definitely not that browser11:04
benbrown_jjardon: fix formatting of description please :)11:04
ssam2and I can't find a way to view the logs without JavaScript11:04
benbrown_chromium seems to manage ok11:04
jjardonsorry,  done11:05
gitlab-br-botybd: merge request (jjardon/cache_location->master: .gitlab-ci.yml: Use /cache to put all contents) #373 changed state ("opened"): https://gitlab.com/baserock/ybd/merge_requests/37311:05
ssam2oh yeah actually Epiphany is doing ok too11:06
ssam2i wish firefox would stop being rubbish at everything :/11:06
gitlab-br-botybd: merge request (jjardon/cache_location->master: .gitlab-ci.yml: Use /cache to put all contents) #373 changed state ("merged"): https://gitlab.com/baserock/ybd/merge_requests/37311:34
ironfootssam2: there are 3 buttons at the top of each job, one of them is to see the raw output without javascript11:36
ironfootfor example: https://gitlab.com/baserock/ybd/-/jobs/22493647/raw11:36
ssam2oh! much better11:36
ssam2ah, except now it has ANSI color codes in11:36
ssam2that's the downside to --color I guess11:36
* ironfoot nods11:37
ssam2I can just download it through `curl | tail` though and get pretty output in my terminal :-)11:37
ironfootmuch better than using a browser :D11:38
ssam2watch -c -d "curl --get https://gitlab.com/baserock/definitions/-/jobs/22498569/raw | tail"11:39
ssam2oh that doesn't work very well, the codes get all messed up11:39
ironfootworks with my "tail"11:41
ironfoot(without watch)11:41
ssam2yeah watch is the issue, but also what would have made it nice11:41
ironfootdoes not work with my "less"11:41
* ironfoot kills cygwin11:42
ssam2:c11:42
ironfootssam2: watch --color11:42
ironfoot(if available, source: random stackoverflow post)11:43
ssam2that's -c, but the colours go a bit weird for me11:43
ssam2probably because 'tail' means we start printing midway through a random code sequence11:44
ironfootxD, next suggestion, while loop, with the clear, curl, sleep11:46
ssam2no cigar11:48
ssam2needs a version of 'tail' that understands ANSI codes really, but that's going a bit far11:48
ironfoot:)11:49
ssam2back to business though,https://gitlab.com/baserock/definitions/-/jobs/22498569 just pushed an artifact to the cache \o/11:49
ironfootyay!11:54
ironfootit's happening in parallel to other jobs, right?11:55
ssam2yeah11:55
ironfoot<311:55
ssam2one small issue I've noticed is that all pull attempts say "success" even when there was no cached artifact found11:56
ironfootyeah, it shouldn't fail11:57
ironfootbut the "success" is confusing11:57
gtristanI agree12:06
gtristanCare to file a bug ?12:07
gtristansuccess is confusing there, it was originally FAILURE, which was much worse12:07
ssam2oof12:07
ssam2sure, will file a bug12:07
gtristanNow it's SUCCESS and INFO appears only if something was downloaded12:07
gtristanqueue status is good to show this in interactive build modes, though12:08
gitlab-br-botinfrastructure: issue #1 ("Set up cache for GitLab CI runners") changed state ("opened") https://gitlab.com/baserock/infrastructure/issues/112:59
gitlab-br-botinfrastructure: issue #2 ("Investigate how to improve job start time on GitLab CI runners") changed state ("opened") https://gitlab.com/baserock/infrastructure/issues/213:05
*** ctbruce has quit IRC13:14
*** gtristan has quit IRC13:41
*** bjdooks has left #baserock13:47
ssam2full build of build-system all pushed to the cache : https://gitlab.com/baserock/definitions/pipelines/987693514:46
ssam2200 minutes to build from scratch .. seems a bit slow14:47
ssam2oh, seems to take 503 minutes with ybd. https://gitlab.com/baserock/definitions/-/jobs/1514038814:50
* ssam2 a bit suspicious about those numbers though14:50
ssam2since the runners always pull all sources, a lot depends on bandwidth14:50
ironfootssam2: wooo!!!14:58
benbrown_how does morph-cache-server actually work for tree queries?15:27
benbrown_is name the path relative to the gits repo on the trove?15:27
benbrown_e.g. 'repo=delta/git'15:28
ssam2not sure15:28
ssam2it's a simple script: http://git.baserock.org/cgit/baserock/baserock/morph.git/tree/morph-cache-server15:28
ssam2I think path is indeed relative15:29
ssam2http://git.baserock.org/cgit/baserock/baserock/morph.git/tree/morphcacheserver/repocache.py#n5415:29
ssam2so depends on the config (in /etc/morph-cache-server.conf)15:30
*** CTtpollard has quit IRC15:57
*** jonathanmaw has quit IRC16:02
*** locallycompact has quit IRC16:30
*** toscalix has quit IRC16:42
*** ssam2 has quit IRC17:46
*** rdale has quit IRC17:52
*** gtristan has joined #baserock18:39
*** gtristan has quit IRC22:08
« Thursday, 2017-07-13 Index Saturday, 2017-07-15 »

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!