| @sahalabakker:matrix.org | Hello! Has the implementation of linear and circular dependency from GitHub to any other version control system been completed, or is it still in progress? | 04:40 |
|---|---|---|
| @anoop-jose:matrix.org | > <@sahalabakker:matrix.org> Hello! Has the implementation of linear and circular dependency from GitHub to any other version control system been completed, or is it still in progress? | 09:37 |
| Could you please elaborate your exact requirement ? | ||
| @sahalabakker:matrix.org | I am currently working on integrating the GitHub and Gerrit repositories. While the linear and circular dependencies are functioning correctly from Gerrit to GitHub, I am encountering issues with the dependencies from GitHub to Gerrit. Could someone assist me in identifying what I might be overlooking? | 10:07 |
| @sahalabakker:matrix.org | In Zuul I have a project(repo) configured with GitHub connection and another in Gerrit. I want to define Depends-On between these two repositories. | 11:59 |
| It can be linear or circular dependency, which merely depends on the changes/patches I place for review. | ||
| While testing Cross project dependency from Gerrit to GitHub I could trigger the pipeline. (That means, the patch from Gerrit depends on a GitHub patch). | ||
| But the Depends-On feature is not working when I define a depends on request from GitHub to Gerrit (GitHub patch depends on Gerrit patch). | ||
| I added change-url of Gerrit patch with Depends-On keyword in Pull Request description in GitHub. | ||
| Could someone assist me in identifying what I might be missing? | ||
| @jim:acmegating.com | sahalabakker: depends-on works between any project and any code review system zuul supports | 13:33 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 14:38 | |
| - [zuul/nodepool] 934043: Temporarily disable release jobs https://review.opendev.org/c/zuul/nodepool/+/934043 | ||
| - [zuul/nodepool] 934044: Restore release jobs https://review.opendev.org/c/zuul/nodepool/+/934044 | ||
| @jim:acmegating.com | zuul-maint: ^ a speedy approval of 934043 would be appreciated | 14:38 |
| @jim:acmegating.com | (and review but not approval of 934044) | 14:38 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 934043: Temporarily disable release jobs https://review.opendev.org/c/zuul/nodepool/+/934043 | 15:49 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 934061: Deprecate Ansible 8 https://review.opendev.org/c/zuul/zuul/+/934061 | 15:53 | |
| @fungicide:matrix.org | looks like the 11.0.0 version of the nodepool docs url now works | 16:46 |
| @fungicide:matrix.org | thanks for fixing! | 16:46 |
| @jim:acmegating.com | yep, sending out the announcement now, and the restore-jobs change is in the queue | 16:48 |
| @mnaser:matrix.org | Upgraded to nodepool 11.0.0 and the world is not yet on fire, wee. thanks all. | 16:53 |
| @mnaser:matrix.org | As my quest for faster image builds with Zuul continues, we've been using the changes in https://review.opendev.org/q/topic:%22native-multiarch-images%22 successfully to avoid a lot of emulation successfully | 16:55 |
| @mnaser:matrix.org | However, the challenge I'm facing still is that.. it is still slow, some images can take up to 20 minutes to build. I'd like to make use of buildkit cache for this kind of thing, but curious if people has experimented with this. | 16:55 |
| @mnaser:matrix.org | Since we can use a Docker registry for cache, and the build jobs _usually_ have access to the intermediate registry, i was thinking that could be a really good option to use to speed up builds | 16:56 |
| @mnaser:matrix.org | https://github.com/vexxhost/atmosphere/pull/1981/checks?check_run_id=32482204136 (i have almost 1h of image builds -- since some depeend on others, when we do big mass rebuilds) -- so trying to speed that up to make our test cycles shorter when we have big image builds | 16:57 |
| @mordred:waterwanders.com | not buildkit cache - but corvus and I did noodling on using shared caches for bazel several years ago. my biggest concern is cache poisoning attacks, so you'd want avoid writing new image layers in check pipelines, although you could likely set up --cache-from even in check pipelines. | 17:00 |
| @jim:acmegating.com | yep; i have a bunch of that actually implemented for bazel. read-only cache in check, writeable cache post-review should generally be safe. | 17:01 |
| @mordred:waterwanders.com | corvus: neat! | 17:02 |
| @mnaser:matrix.org | > <@mordred:waterwanders.com> not buildkit cache - but corvus and I did noodling on using shared caches for bazel several years ago. my biggest concern is cache poisoning attacks, so you'd want avoid writing new image layers in check pipelines, although you could likely set up --cache-from even in check pipelines. | 17:02 |
| I was thinking --cache-from main + --cache-from <branch-specific> + --cache-to <branch-specific> in check so that further checks could actually not be so slow -- and if i wire that up inside the role itself | ||
| @mnaser:matrix.org | > <@mordred:waterwanders.com> not buildkit cache - but corvus and I did noodling on using shared caches for bazel several years ago. my biggest concern is cache poisoning attacks, so you'd want avoid writing new image layers in check pipelines, although you could likely set up --cache-from even in check pipelines. | 17:03 |
| * I was thinking --cache-from main + --cache-from \<branch-specific> + --cache-to \<branch-specific> in check so that further checks could actually not be so slow -- and if i wire that up inside the role itself then dont need to worry about users messing things up | ||
| @mnaser:matrix.org | > <@mnaser:matrix.org> I was thinking --cache-from main + --cache-from \<branch-specific> + --cache-to \<branch-specific> in check so that further checks could actually not be so slow -- and if i wire that up inside the role itself then dont need to worry about users messing things up | 17:03 |
| (since the role runs from the config repo) | ||
| @mordred:waterwanders.com | well - the biggest risk there is having the job content in check having credentials to write to the cache at all ... because if the node has the creds, then a malicious user can push up a malicious change that uses the creds to write gork into the cache. but I'm still very much on first coffee | 17:06 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 934044: Restore release jobs https://review.opendev.org/c/zuul/nodepool/+/934044 | 17:20 | |
| @clarkb:matrix.org | I'm looking at Gerrit 3.10 upgrade stuff and https://gerrit-review.googlesource.com/c/gerrit/+/404717 seems like it may generally affect zuul if zuul is using change numbers without project info for reporting things? | 18:43 |
| @clarkb:matrix.org | In particular it seems like Gerrit won't guarantee unique change numbers anymore if you import projects from other gerrit servers and thus you need project to make a unique tuple. | 18:44 |
| @clarkb:matrix.org | corvus: ^ any immediate concerns about that in Zuul? I think OpenDev is fine because we haven't (yet) imported any projects from other Gerrit servers | 18:44 |
| @clarkb:matrix.org | we're fine from a lack of collisions standpoint but Gerrit will start requiring the unique project,changenumber tuple so Zuul may break post upgrade if not doing that | 18:46 |
| @jim:acmegating.com | Clark: that particular change won't affect zuul because it already uses the project there. however, if there are duplicate change numbers in a gerrit, that could present a problem. | 19:13 |
| @clarkb:matrix.org | Ok I don't think we have that issue in opendev since it seems to be a side effect of importing a project from another Gerrit where change numbers may have overlapped | 19:22 |
| @clarkb:matrix.org | I wonder if we should make a note about that in the Gerrit driver docs for zuul | 19:22 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 930387: Provide config error information for dependency cycles https://review.opendev.org/c/zuul/zuul/+/930387 | 19:48 | |
| @jim:acmegating.com | not a bad idea | 19:56 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 932367: Add test of topic dependencies with an abandoned change https://review.opendev.org/c/zuul/zuul/+/932367 | 20:46 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 932368: Fix race with topic changes https://review.opendev.org/c/zuul/zuul/+/932368 | 20:53 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 934089: Add a note about Zuul not handling Gerrit chagne number collisions https://review.opendev.org/c/zuul/zuul/+/934089 | 20:57 | |
| @clarkb:matrix.org | something like that for the docs? | 20:57 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 934090: Use local cache sync instead of remote https://review.opendev.org/c/zuul/zuul/+/934090 | 21:02 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 934090: Use local cache sync instead of remote https://review.opendev.org/c/zuul/zuul/+/934090 | 21:03 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 933607: DNM: test race battery https://review.opendev.org/c/zuul/zuul/+/933607 | 21:05 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 934061: Deprecate Ansible 8 https://review.opendev.org/c/zuul/zuul/+/934061 | 21:07 | |
| @mnaser:matrix.org | > <@mordred:waterwanders.com> well - the biggest risk there is having the job content in check having credentials to write to the cache at all ... because if the node has the creds, then a malicious user can push up a malicious change that uses the creds to write gork into the cache. but I'm still very much on first coffee | 21:29 |
| yeah hoooowever since the build container image jobs that are using intermediate registry are generally in a config project, they cant really be modified unless the config job is changed (since they use credentials to auth to intermediate registry) | ||
| @mordred:waterwanders.com | mnaser: good point if those jobs have credentials already | 23:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!