[ 
https://issues.apache.org/jira/browse/DISPATCH-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170841#comment-17170841
 ] 

ASF GitHub Bot commented on DISPATCH-1739:
------------------------------------------

gemmellr commented on pull request #809:
URL: https://github.com/apache/qpid-dispatch/pull/809#issuecomment-668642821


   > Note that ctest -j2 results in test log lines being mixed up in stdout.
   Refer to the output XML report or use grep (grep for lines starting with
   the test number) to get understandable logs.
   
   Or not use -j2? How much of a difference does it make? You commented later 
its mainly for excercising bwrap and is more useful on Travis.
   
   > Using four shards, as adding more does not help much.
   
   Presumably due to all the setup costs relative to the time spent on tests, 
or the fact 1 shard is clearly longer than others and maybe still ends up that 
way?
   
   Also, did you try less than 4? I see one of them has a test run around twice 
as long as most others, so unless all the long-running tests are perfectly 
spaced to fall in that shard, is it possible having less shards might actually 
distribute the test time more evenly such that it isnt much slower overall (if 
at all; it could even be faster if the tests group better), while giving less 
different output areas to look at (not personally a huge fan of the sharding, 
significantly complicates the build config and results, may point to some 
inefficient tests that it seems needed to begin with)
   
   > I also couldn't find a way to use here the artifacts that the Proton 
pipeline is building.
   
   I think thats fine, possibly even preferable. Its not that lengthy a build, 
and its likely to eventually want different versions as e.g the Travis tests 
use.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


> Use GitHub Actions w/ sharding and bubblewrap for some fast CI
> --------------------------------------------------------------
>
>                 Key: DISPATCH-1739
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-1739
>             Project: Qpid Dispatch
>          Issue Type: Improvement
>          Components: Tests
>    Affects Versions: 1.12.0
>            Reporter: Jiri Daněk
>            Assignee: Jiri Daněk
>            Priority: Major
>             Fix For: 1.13.0
>
>
> GitHub Actions is a task runner associated with a GitHub project. It is 
> conceptually similar to Travis, except that it has some extra features, and 
> the waits for computational resources are much shorter (currently).
> Sharding is a technique to speed up the execution of tests. Instead of 
> running the tests on one machine one after another, copy the build directory 
> over to multiple machines, say two, and have the first execute the 
> odd-numbered and the second one the even-numbered tests. With luck (if 
> copying the build directory is relatively fast, and the tests all take 
> approximately the same time), this will cut the execution time in half.
> Bubblewrap (https://github.com/containers/bubblewrap) is a sandboxing tool 
> available on Ubuntu and other systems. It is similar to systemd-nspawn except 
> it does not require sudo or user namespace support in the kernel. It is 
> similar to docker, except it does not use images, instead it selectively 
> mounts directories from the host. Bubblewrap can create an isolated network 
> namespace, which allows running multiple tests at the same time, each in its 
> own bubblewrap sandbox, and they don't clash on ports. With bubblewrap, 
> running {{ctest -j4}} is safe.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to