| *** tristan has joined #buildstream | 06:37 | |
| *** ChanServ sets mode: +o tristan | 07:07 | |
| *** jude has joined #buildstream | 08:30 | |
| *** jonathanmaw has joined #buildstream | 09:00 | |
| *** persia has quit IRC | 09:38 | |
| *** persia has joined #buildstream | 09:40 | |
| tristan | jjardon[m], so I'm trying to find a work around | 11:27 |
|---|---|---|
| tristan | but I found out what is causing the crazy, I was right | 11:27 |
| tristan | See added comment on https://github.com/ostreedev/ostree/issues/633 | 11:28 |
| jjardon[m] | tristan: nice, so maybe we can use an older ostree version in the meantime? Does the ostree used in buildstream comes from the host or from the bst definitions? | 11:31 |
| tristan | jjardon[m], its the artifact cache and a Source implementation; in both cases we require it from the host | 11:35 |
| tristan | I know v2016.14 to work, but I'm testing some workaround now | 11:35 |
| tristan | I tried using the uncompressed cache, which doesnt suffer the problem, but it's piss slow | 11:36 |
| tristan | Now trying to just only use bare-user mode repositories for buildstream (it's the repo mode we already use for artifact cache, but now trying that for the ostree source too) | 11:36 |
| tristan | I have same problem it turns out on the aarch64 host because I needed to install ostree by hand there | 11:37 |
| tristan | also using the compressed cache is just pretty silly for the ostree source; it will end up taking 1.5 times the disk space | 11:41 |
| tristan | whew this is a looooong test :( | 12:09 |
| *** tristan has quit IRC | 12:16 | |
| *** tristan has joined #buildstream | 12:28 | |
| *** ChanServ sets mode: +o tristan | 12:33 | |
| violeta | I've added the import test I've been working on to my repo. It has a script that carries out the test to check that the files are as expected, including permissions. In future this would have a ./run-tests.sh script to run every script for every test. I'm sure there are a lot of problems with the format, but there's still work to do on it https://gitlab.com/VioletaMG/buildstream-tests/tree/violeta/test-suite | 12:40 |
| tristan | violeta, good start ! | 12:50 |
| tristan | violeta, first impressions are, I like that the script has a concept of collecting things and testing them automatically | 12:51 |
| tristan | If I'm reading it right at a glance: I dont like that the script does `bst build` && `bst checkout` of everything first, and then proceeds to test output only afterwards | 12:52 |
| tristan | in any case, there are many approaches with bash | 12:53 |
| tristan | just that part is, better to run & test each thing (tests will eventually become long running things, we'll want to know which ones fail right away) | 12:53 |
| violeta | ok, makes sense | 12:53 |
| tristan | maybe in the same way that you enumerate directories in a loop, we can have directories which contain scripts; and the master loop can source them and run a test function for each in a loop | 12:54 |
| tristan | i.e. assuming each test script has a "function test() { ... }" or such | 12:55 |
| tristan | and those can source some common utility functions (for testing permissions or running builds etc) | 12:55 |
| persia | Any chance of testing with yarn or similar? | 12:56 |
| tristan | I dont know what yarn is | 12:56 |
| tristan | looks like something that emerged from nodejs ? | 12:57 |
| persia | https://blog.liw.fi/posts/yarn | 12:57 |
| violeta | good point, I think it'll be cleaner that way | 12:58 |
| tristan | I dont know, I dont want to make things more complicated than they should be, to be honest | 12:59 |
| violeta | (my comment was to the individual test scripts) | 12:59 |
| tristan | if it is simple and appropriate for the use cases, then sure | 12:59 |
| persia | In my experience, yarn tests are simple to read, and comprehensive for functional testing for anything with a primary interface as a command-line. | 13:00 |
| tristan | but yeah, violeta, dont bust your brain cells overcomplicating things just because someone thought up an ultra fancy testing framework that will cause us to lose time wrapping our heads around | 13:00 |
| persia | Oh indeed. My suggestion to use yarn isn't intended to slow anything :) | 13:01 |
| tristan | it would be interesting to, for instance, have a bunch of tests on different host scenarios, assert graceful failures for projects that want to use git but have no git installed etc, but we are also bound by gitlab runners | 13:02 |
| violeta | but that's not testing Buildstream, but testing different host environments? | 13:08 |
| violeta | not sure if I've misunderstood | 13:08 |
| tristan | violeta, no disregard that comment, it's a nice-to-have-but-we're-not-gonna-have-it-for-now | 13:08 |
| violeta | ok | 13:09 |
| tristan | violeta, just to clarify what that was about, it's about fault tolerance or more specifically, failing gracefully; BuildStream does not require host git or host bzr; but projects which use git plugins _do_, tests could theoretically be made to ensure that buildstream informs the user gracefully before spending hours processing just to find that there is not git installed on the host | 13:10 |
| violeta | it's kind of close to my time for leaving, what useful things could I do? Just continue improving the script with the comments you've made? Do we have a list of the things we want to test or is something we are thinking currently? | 13:10 |
| tristan | but let's file that category of tests into unrelated for now | 13:10 |
| violeta | ok | 13:11 |
| tristan | violeta, improve structure based on my comments is one thing yeah, ensure that we have exercised all the options of the import plugin, and then I think next lets do some basic build element tests on softwares we know to build reliably without much dependencies beyond a runtime | 13:12 |
| tristan | after that we'll want tests for compose elements | 13:12 |
| tristan | violeta, also do we want a structure with many subdirs with separate projects ? | 13:13 |
| tristan | It may be | 13:13 |
| tristan | I see you structured it that way, and it's probably a good idea | 13:13 |
| tristan | in any case, we should have a simple ./run-tests.sh or such at the top level which iterates the subdirs | 13:14 |
| violeta | yes, that was my idea | 13:14 |
| tristan | alright looking good :) | 13:15 |
| * tristan is going away now too... | 13:15 | |
| violeta | and I thought that even if everything is on one branch, we could have one project for each related set of tests. But if it doesn't make much sense I can change that, I just did it now that we have only one test | 13:15 |
| violeta | ok, have a nice evening o/ | 13:15 |
| tristan | good news is, I have built 12 modules so far... converted from jhbuild... on Aarch64 ! | 13:15 |
| violeta | see you in two weeks :-) | 13:15 |
| tristan | With a work around to the ostree bug, but I'm not happy with the workaround | 13:16 |
| tristan | Okaaay 2 weeks I have to wait for you ! | 13:16 |
| * tristan sets timer | 13:16 | |
| violeta | :-) | 13:16 |
| gitlab-br-bot | buildstream: merge request (jonathan/enhance-script-element->master: Jonathan/enhance script element) #22 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/22 | 15:28 |
| *** jonathanmaw has quit IRC | 16:56 | |
| *** tiagogomes has quit IRC | 17:03 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!