Hi Vagrant,

On Samstag, 19. Dezember 2015, Vagrant Cascadian wrote:
> I didn't spend any time really figuring out which nodes to add to the
> example 16th build job, so that might need some adjusting.

put some 4cores in one pool, and 2cores in another?
> - Split load estimating into it's own script, and add support for
> available memory.

I'd still suggest to measure the load constantly by a job outside the build 
script… (then it's also easy to read "not updated node load since $time" as 
"node is to busy to be scheduled on…)
> - Call timeout so that the ssh processes don't take too long to complete.

see above, don't ssh from the build script please.
> diff --git a/bin/reproducible_build.sh b/bin/reproducible_build.sh

I'll only comment on the most "pressing" issues now.

>  build_rebuild() {
>       FTBFS=1
>       mkdir b1 b2
> +     local selected_node
> +     selected_node=$(select_least_loaded_node $NODE1_POOL)

please make this somehow conditional so that this code path is not used for 
"normal operation" (=without this new pooling), so we can test this easily on 
one builder job, but not on all.

so for builder_armhf_16…:

> +++ b/job-cfg/reproducible.yaml
> +                - '16': { my_node1: 'wbd0-armhf-rb:2223
> wbq0-armhf-r:2225', my_node2: 'bpi0-armhf-rb:2222 odxu4-armhf-rb:2229' } +
>            my_shell: '/srv/jenkins/bin/reproducible_build.sh "{my_node1}"

…reproducible_build.sh should probably be called with "experimental-pooling" 
as first param, which is then shifted away…


Attachment: signature.asc
Description: This is a digitally signed message part.

Reproducible-builds mailing list

Reply via email to