@jim:acmegating.com | > <@chgans:matrix.org> So Zull will give me repo with what has changed (inc. speculative stuff), but the build/test environement still need access the the whole source tree. and this source tree need to be in a specific state (git refs)... | 05:42 |
---|---|---|
Zuul will provide the entire source tree, including all branches and tags, with the speculative future state (since more than one branch can be changed). It will also provide any other repos necessary even if they aren't being changed; they can be specified by "required-projects", and it will ensure that all of them share the same state within a single buildset (set of jobs for a change). It will also check out all the repos to an appropriate branch (based on the job definition, the change under test, any branch pragmas within zuul that have been set, required-project branch overrides, etc). | ||
@chgans:matrix.org | It's both a good and bad news. Bad news is that the "required projects" is specified in the AOSP manifest repo. It's not structural metadata that stay in the zull project config. | 05:48 |
@chgans:matrix.org | Building aosp is driven by the manifest repo branch tag. It is actually very similar to a mega repo where everything is just git sub modules. | 05:49 |
@chgans:matrix.org | Branch/tag | 05:50 |
@tibeer:matrix.org | Hello, i kindly wanted to ask if someone has interest in reviewing my patch: https://review.opendev.org/c/zuul/zuul/+/845124. TLDR: Triggering workflows manually from GitHub trough GitHub Actions should now be possible. | 07:12 |
-@gerrit:opendev.org- Artem Goncharov proposed wip: [zuul/zuul] 813136: Check blocking_discussions_resolved in gitlab driver https://review.opendev.org/c/zuul/zuul/+/813136 | 07:24 | |
-@gerrit:opendev.org- Artem Goncharov proposed wip: [zuul/zuul] 813136: Check blocking_discussions_resolved in gitlab driver https://review.opendev.org/c/zuul/zuul/+/813136 | 08:52 | |
-@gerrit:opendev.org- Artem Goncharov proposed wip: [zuul/zuul] 813136: Check blocking_discussions_resolved in gitlab driver https://review.opendev.org/c/zuul/zuul/+/813136 | 11:08 | |
@g_gobi:matrix.org | > <@g_gobi:matrix.org> - project: | 12:08 |
> name: proj-name | ||
> default-branch: master | ||
> merge-mode: squash-merge | ||
> gate: | ||
> jobs: | ||
> - lint (example) | ||
> - code-fmt (example) | ||
> So, if we configure like that. It will run both lint and code-fmt like above (parallel). Am I right? | ||
Is there any option available to run next job (3 rd) after the first 2 gets finished successfully? If any one of them failed, 3rd job should be skipped. | ||
@g_gobi:matrix.org | * Hi, | 12:09 |
Is there any option available to run next job (3 rd) after the first 2 gets finished successfully? If any one of them failed, 3rd job should be skipped. | ||
@g_gobi:matrix.org | * Hi, | 12:09 |
Is there any option available to run next job (3 rd) after the first 2 gets finished successfully? If any one of them failed, 3rd job should be skipped. I tried https://zuul-ci.org/docs/zuul/latest/config/job.html?highlight=depen#attr-job.requires but it starts all the jobs parallel. | ||
@q:fricklercloud.de | https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.dependencies | 12:14 |
-@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 817393: Fix gitlab squash merge https://review.opendev.org/c/zuul/zuul/+/817393 | 12:15 | |
@g_gobi:matrix.org | frickler: thank you. It worked as expected👏 | 12:20 |
@g_gobi:matrix.org | Also, one more doubt. | 12:24 |
I have 3 jobs. like | ||
- JobA | ||
- JobB | ||
- JobC | ||
Is there any option to skip jobB before it started? like gitlab jobs have when condition | ||
@g_gobi:matrix.org | Job has `job.files` option. It will trigger a job if any change in the specified file. I want to know is there any option like | 12:33 |
If any specified content changes in the file, trigger the job else skip it. | ||
-@gerrit:opendev.org- Artem Goncharov marked as active: [zuul/zuul] 813136: Check blocking_discussions_resolved in gitlab driver https://review.opendev.org/c/zuul/zuul/+/813136 | 13:11 | |
@g_gobi:matrix.org | > <@g_gobi:matrix.org> Job has `job.files` option. It will trigger a job if any change in the specified file. I want to know is there any option like | 13:17 |
> If any specified content changes in the file, trigger the job else skip it. | ||
My case (example) is like I have one config file. | ||
It contains what are all the platforms/targets/repos I need to run the test against: | ||
Like | ||
Mac: yes | ||
Windows: yes | ||
linux: no | ||
I hva | ||
@g_gobi:matrix.org | * My case (example) is like I have one config file. | 13:17 |
It contains what are all the platforms/targets/repos I need to run the test against: | ||
Like | ||
``` | ||
config file | ||
Mac: yes | ||
Windows: yes | ||
linux: no | ||
``` | ||
@g_gobi:matrix.org | * My case (example) is like I have one config file. | 13:17 |
It contains what are all the platforms/targets/repos I need to run the test against: | ||
Like | ||
`config file` | ||
``` | ||
Mac: yes | ||
Windows: yes | ||
linux: no | ||
``` | ||
@g_gobi:matrix.org | * My case (example) is like I have one config file. | 13:19 |
It contains what are all the platforms/targets/repos I need to run the test against: | ||
Like | ||
`config file` | ||
``` | ||
Mac: yes | ||
Windows: yes | ||
linux: no | ||
``` | ||
`Pipeline:` | ||
``` | ||
jobs: | ||
- mac | ||
- windows | ||
- linux | ||
``` | ||
I need to run what are all the values marked as **yes** | ||
@g_gobi:matrix.org | * My case (example) is like I have one config file. | 13:20 |
It contains what are all the platforms/targets/repos I need to run the test against: | ||
Like | ||
`config file` | ||
``` | ||
Mac: yes | ||
Windows: yes | ||
linux: no | ||
``` | ||
`Pipeline:` | ||
``` | ||
jobs: | ||
- mac | ||
- windows | ||
- linux | ||
``` | ||
I need to run what are all the values marked as **yes**. | ||
Mostly what are all the values changed(if possible). | ||
@q:fricklercloud.de | I think that that is out of scope for zuul. maybe you could workaround with a pre-commit script that amends your project config accordingly, assuming it is in-repo, but I'm not sure if that is too dynamic | 13:24 |
@g_gobi:matrix.org | > <@q:fricklercloud.de> I think that that is out of scope for zuul. maybe you could workaround with a pre-commit script that amends your project config accordingly, assuming it is in-repo, but I'm not sure if that is too dynamic | 13:31 |
ok frickler thanks for the info. Then i'll trigger jobs and check the changes and skip accordingly. | ||
@g_gobi:matrix.org | I'm seeing **`DISK_FULL`** as a build result. Both my worker node and server nodes have more than 50% available disk space. Any idea why this error? | 14:00 |
@g_gobi:matrix.org | * I'm seeing **`DISK_FULL`** as the build result. Both my worker node and server nodes have more than 50% available disk space. Any idea why this error? | 14:00 |
-@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 845592: [WIP] Add Gitlab commit status reporting https://review.opendev.org/c/zuul/zuul/+/845592 | 14:11 | |
-@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 817393: Fix gitlab squash merge https://review.opendev.org/c/zuul/zuul/+/817393 | 14:14 | |
@clarkb:matrix.org | > <@g_gobi:matrix.org> I'm seeing **`DISK_FULL`** as the build result. Both my worker node and server nodes have more than 50% available disk space. Any idea why this error? | 14:28 |
There is a configurable per job limit. You should determine if your limit is too low or if the jobs are using excessive disk | ||
@g_gobi:matrix.org | Clark: Can you please pass the attribute here? | 14:36 |
@g_gobi:matrix.org | * Clark: Can you please pass the attribute here? or share the details where I have to look | 14:51 |
@q:fricklercloud.de | > <@g_gobi:matrix.org> Clark: Can you please pass the attribute here? or share the details where I have to look | 14:55 |
https://zuul-ci.org/docs/zuul/latest/configuration.html#attr-executor.disk_limit_per_job | ||
@g_gobi:matrix.org | Thanks frickler and Clark . looks like default value is 250 mb. Then test logs exceeded that much.🤔 | 14:58 |
-@gerrit:opendev.org- Artem Goncharov proposed: [zuul/zuul] 845592: [WIP] Add Gitlab commit status reporting https://review.opendev.org/c/zuul/zuul/+/845592 | 15:00 | |
@g_gobi:matrix.org | ``` | 15:11 |
du -sh .../zuul/builds/<build-id>/work | ||
692Mwork/ | ||
``` | ||
looks like the size was 692 MB. As per the doc, it should abort the job after 250MB right? or it should look some other specific directory for the storage limit? | ||
@fungicide:matrix.org | > <@g_gobi:matrix.org> ``` | 15:20 |
> du -sh .../zuul/builds/<build-id>/work | ||
> 692Mwork/ | ||
> ``` | ||
> looks like the size was 692 MB. As per the doc, it should abort the job after 250MB right? or it should look some other specific directory for the storage limit? | ||
The usage checker happens in a separate periodic thread, and so can race the accumulation of files past the specified limit. | ||
@fungicide:matrix.org | it's real task is to make sure you don't merge changes which increase on-executor disk usage past the configured amount. | 15:21 |
@fungicide:matrix.org | * Its real task is to make sure you don't merge changes which increase on-executor disk usage past the configured amount. | 15:21 |
@g_gobi:matrix.org | fungi: okay. This disk usage will refer the specific build path /zuul/builds/<build-id> of the job right? | 15:39 |
@clarkb:matrix.org | > <@g_gobi:matrix.org> fungi: okay. This disk usage will refer the specific build path /zuul/builds/<build-id> of the job right? | 15:49 |
correct | ||
@fungicide:matrix.org | yes, it's a semi-passive approach to keeping executor disk utilization under control, in order to avoid tripping the governor which causes the executor to avoid taking new builds (or worse, actually filling up its filesystem and breaking other running builds) | 16:47 |
@fungicide:matrix.org | perhaps someone in here has a twitter account and an opinion on https://twitter.com/skamille/status/1535371206915940353 | 20:29 |
@blaisepabon:matrix.org | https://twitter.com/controlpl4n3/status/1536465483049877505 | 21:48 |
@fungicide:matrix.org | oh, hey! great article to link ;) | 22:03 |
@blaisep-sureify:matrix.org | I love that article. | 23:43 |
@blaisep-sureify:matrix.org | That article helped me build some some momentum at $DAYJOB for adopting Zuul. | 23:47 |
I'm supposed to do a demo on Wed and I was going to use softwarefactory, but I just could not get it to complete the installation. | ||
The folks there were very helpful, but the bottom line seems to be that it only runs on centos 7 (w/out `epel`) and that is anathema to modern ACME clients. | ||
@chgans:matrix.org | Any link to this "softwarefactory" thing? I'm curious. | 23:52 |
@blaisep-sureify:matrix.org | softwarefactory-project.io | 23:54 |
@blaisep-sureify:matrix.org | It seems to be a group of red hatters putting together a disto of zuul-ci and other goodies. | 23:55 |
@blaisep-sureify:matrix.org | Some of the opendev folks are also involved. | 23:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!