Thursday, 2024-03-28

@tristanc_:matrix.orgAlbin Vass: have you tried something like https://github.com/TristanCacqueray/zuul-nix/blob/master/zuul.nix#L3-L7 ?12:58
@sylvass:albinvass.setristanC: yeah, but the version in the flake could easily be forgotten and would stay at 10.0.0. So I might as well keep the build outside of the zuul-client repo13:15
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 914658: Fix inheritance of delete-after-upload option https://review.opendev.org/c/zuul/nodepool/+/91465816:19
-@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 914658: Fix inheritance of delete-after-upload option https://review.opendev.org/c/zuul/nodepool/+/91465817:57
@vlotorev:matrix.orgHi,20:48
this commit in zuul/zuul started writing `.git/packed-refs` file - https://opendev.org/zuul/zuul/commit/518194af1dca82dd42ae5b599cb2e1d817031068?style=split&whitespace=show-all&show-outdated=#diff-2e459048c0e4a2f61e4975290ed881f0e3ddc31c
It seems zuul generates .git/packed-refs file improperly, `git describe` in git repo directory returns:
```
fatal: No annotated tags can describe 'db62e....'.
However, there were unannotated tags: try --tags.
```
Indeed proper `.git/packed-refs` has extra line starting with `^<SHA>` after lines with tag while packed-refs generated by zuul doesn't `^<SHA>` lines.
This issue is not reproduced on zuul.opendev.org because git repo prepared by merger is uploaded to CI nodes using `prepare-workspace-git` role. This role does `git push` and .git/packed-refs is regenerated on CI node.
I found this issue while using `prepare-workspace` role. This roles uses rsync to upload files and `.git/packed-refs` is copied 'as is' on node and hence `git describe` fails while running playbook.
@vlotorev:matrix.org * Hi,20:49
this commit in zuul/zuul started writing `.git/packed-refs` file - https://opendev.org/zuul/zuul/commit/518194af1dca82dd42ae5b599cb2e1d817031068?style=split&whitespace=show-all&show-outdated=#diff-2e459048c0e4a2f61e4975290ed881f0e3ddc31c
It seems zuul generates .git/packed-refs file improperly, `git describe` in git repo with annotated tags fails with error:
```
fatal: No annotated tags can describe 'db62e....'.
However, there were unannotated tags: try --tags.
```
Indeed proper `.git/packed-refs` has extra line starting with `^<SHA>` after lines with tag while packed-refs generated by zuul doesn't `^<SHA>` lines.
This issue is not reproduced on zuul.opendev.org because git repo prepared by merger is uploaded to CI nodes using `prepare-workspace-git` role. This role does `git push` and .git/packed-refs is regenerated on CI node.
I found this issue while using `prepare-workspace` role. This roles uses rsync to upload files and `.git/packed-refs` is copied 'as is' on node and hence `git describe` fails while running playbook.
@vlotorev:matrix.org * Hi,20:50
this commit in zuul/zuul started writing `.git/packed-refs` file - https://opendev.org/zuul/zuul/commit/518194af1dca82dd42ae5b599cb2e1d817031068?style=split&whitespace=show-all&show-outdated=#diff-2e459048c0e4a2f61e4975290ed881f0e3ddc31c
It seems zuul generates .git/packed-refs file improperly, `git describe` in git repo with annotated tags fails with error:
```
fatal: No annotated tags can describe 'db62e....'.
However, there were unannotated tags: try --tags.
```
Indeed proper `.git/packed-refs` has extra line starting with `^<SHA>` after lines with tag while packed-refs generated by zuul doesn't `^<SHA>` lines (note leading `^` at the beginning).
This issue is not reproduced on zuul.opendev.org because git repo prepared by merger is uploaded to CI nodes using `prepare-workspace-git` role. This role does `git push` and .git/packed-refs is regenerated on CI node.
I found this issue while using `prepare-workspace` role. This roles uses rsync to upload files and `.git/packed-refs` is copied 'as is' on node and hence `git describe` fails while running playbook.
@clarkb:matrix.orgvlotorev: the motivation behind that change was a fairly large speedup in merger performance. That said one of my concerns was that we'd somehwo get the format wrong. Are you able to share a more concrete example of the problem?20:52
@vlotorev:matrix.orgjust run `git describe` in repo prepared by merger20:53
@clarkb:matrix.orgno I understand that. I meant the format differences but I think I see them in the zuul repo itself20:53
@clarkb:matrix.orgI think those entries may be for tags20:53
@clarkb:matrix.orglooks like this in zuul:20:54
```
```
@clarkb:matrix.org * looks like this in zuul:20:54
```
7ce69d5a7b0a9db9d33604f54bb09ae7f4e3679d refs/tags/1.1.0
^ad61501575100c6992f4109bdac045aab5c16809
```
@jim:acmegating.comthe second one is the signature object20:55
@clarkb:matrix.org`7ce69` is the hash of the tag object and `ad6150` is the ref the tag points to?20:55
@clarkb:matrix.orgah ok20:55
@jim:acmegating.comno that's backwards, you're right clark20:56
@jim:acmegating.com * the first one is the signed tag object the second in the ref it points to20:56
@jim:acmegating.com * yep :)20:57
@clarkb:matrix.orgso I guess when writing out refs/tags we need to add entries for the target refs20:58
@clarkb:matrix.org```21:02
diff --git a/zuul/merger/merger.py b/zuul/merger/merger.py
index 452ebb854..8469955bb 100644
--- a/zuul/merger/merger.py
+++ b/zuul/merger/merger.py
@@ -554,6 +554,12 @@ class Repo(object):
repo.odb.info(binsha)
f.write(f'{hexsha} {path}\n'.encode(encoding))
msg = f"Set reference {path} at {hexsha} in {repo.git_dir}"
+ if path.startswith('refs/tags/'):
+ # Tags are special as they have a ref for the tag
+ # object and a ref for the target commit
+ # TODO determine tag_target_hexsha
+ f.write(f'^{tag_target_hexsha}\n'.encode(encoding))
+ msg += f" with tag target {tag_target_hexsha}"
if log:
log.debug(msg)
else:
```
@clarkb:matrix.orgSomething like that maybe?21:02
@clarkb:matrix.orgI've channeled my inner mordred and left out the tricky bit determining the tag target hexsha for now21:02
@clarkb:matrix.orgok I think I have it after some local testing with gitpython. Now to see if any test cases need updating21:10
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 914715: Handle tags when packing refs https://review.opendev.org/c/zuul/zuul/+/91471521:38
@clarkb:matrix.orgThere is one piece in there I'm not quite sure about which I'll leave a comment on21:38
@clarkb:matrix.orgok posted. corvus you may know?21:42
@jim:acmegating.comClark: it's only signed tags that have the extra line21:44
@clarkb:matrix.orgreally? I guess regular tags don't have an object and are just a normal ref?21:49
@jim:acmegating.comyep like a symlink21:49
@clarkb:matrix.orgok that means we need to check if tag.object exists and if so then do the work21:49
@clarkb:matrix.organd my test isn't valid21:50
@jim:acmegating.comClark: yeah, i wrote some comments on that change21:51
@jim:acmegating.comClark: gitpython docs say that if it's a tag object then `.object` should be the object it points to21:53
@jim:acmegating.comClark: though it looks like `repo.commit(hexsha)` will return the pointed-to commit21:59
@jim:acmegating.comhowever, i'm not sure how fast/slow repo.commit is, so we would need to benchmark it with tens of thousands of tags to make sure we're not adding to the runtime; if it's too slow, we'll need to get the data from the repo state22:01
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed:22:02
- [zuul/zuul] 914415: Move fake gerrit and pagure into dedicated files https://review.opendev.org/c/zuul/zuul/+/914415
- [zuul/zuul] 914561: Make the test change database serializable https://review.opendev.org/c/zuul/zuul/+/914561
- [zuul/zuul] 914562: Add an upgrade test https://review.opendev.org/c/zuul/zuul/+/914562
@clarkb:matrix.orgcorvus: ok I was using repo.rev_parse22:04
@clarkb:matrix.orgcorvus: if that is a signed tag we get back a TagObject which .object is the commit pointed to otherwise we get a Commit object if it is unsigned22:05
@jim:acmegating.comrev_parse is doing a lot of extra work since we know we're starting with a hexsha22:06
@clarkb:matrix.orgya I guess if repo.commit(hexsha).hexsha does not equal the origianl hexsha then we know we're a signed tag?22:06
@jim:acmegating.comseems reasonable22:07
@clarkb:matrix.orgcorvus: any idea how to test this properly? I don't know that we have gpg configured for signing tags in the zuul test suite?22:10
@jim:acmegating.comClark: no, it seems like it might be a lot of work to set up gpg just for a unit test.  could maybe stick an entire git repo with a signed tag in there as a fixture, but that's probably almost as much work.  either way i don't think it's going to be easy.22:11
@jim:acmegating.com(especially fighting the new gpg daemon)22:12
@clarkb:matrix.orgLooks like annotated tags have the same behavior so we don't actually need to sign anything22:16
@jim:acmegating.comah cool22:18
@jim:acmegating.comClark: then we should have an end-to-end test where we put an annotated tag in the repo so that we get the input data from the repo state (to validate the assertion than the tag points to the tag object not the commit)22:20
@jim:acmegating.comvlotorev: which sha did zuul write, the tag sha or commit sha?22:22
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 914715: Handle annotated and signed tags when packing refs https://review.opendev.org/c/zuul/zuul/+/91471522:27
@clarkb:matrix.orgcorvus: oh I like the idea of an end to end test. That latest patchset doesn't do that but does do the more unittest testing22:28
@clarkb:matrix.orgvlotorev: ya that info would be helpful as spot checking zuul's repo on a zuul merger and a zuul executor shows valid packged refs22:31
@clarkb:matrix.orgso we aren't going through the code paths that reset everything there I guess?22:31
@jim:acmegating.comyeah, that's only used in a workspace checkout22:32
@clarkb:matrix.orgaha22:32
@clarkb:matrix.orgI found a builds/uuid entry with openstack/tempest in it but then packed_refs only has master in it22:34
@clarkb:matrix.orgI think I found one that should give us info22:35
@clarkb:matrix.orgopenstack/neutron-tempest-plugin has `1f418b95227975058463464ae327470e3672f686 refs/tags/0.1.0` in it22:35
@clarkb:matrix.orgI think that is the tag object hash and not the commit hash22:38
@clarkb:matrix.orgso my assumption in the change I wrong should hold22:38
@jim:acmegating.comClark: good, that looks like the tag object, which is what we expected.  i also manually tested the merger repo state code and got the same thing.  we should still add the end-to-end test, but i think that's good.22:38
@vlotorev:matrix.orgcorvus: here is logs for repo cloned from gerrit and for repo fetched from CI node:22:39
```
$ cat sandbox/.git/packed-refs
# pack-refs with: peeled fully-peeled sorted
f14249f65247fa8ae273d52a185c8f3afae45a28 refs/remotes/origin/master
24d70188aae833bb4fd43f16cb6f5cde3392e7f4 refs/tags/0.1
^f14249f65247fa8ae273d52a185c8f3afae45a28
$ cat zuul-sandbox/.git/packed-refs
# pack-refs with: peeled fully-peeled sorted
db62e3c9bbebb7e77dead2009eea3922832faade refs/heads/master
f14249f65247fa8ae273d52a185c8f3afae45a28 refs/remotes/origin/master
24d70188aae833bb4fd43f16cb6f5cde3392e7f4 refs/tags/0.1
db62e3c9bbebb7e77dead2009eea3922832faade refs/zuul/4f26aeafdb2367620a393c973eddbe8f8b846ebd
db62e3c9bbebb7e77dead2009eea3922832faade refs/zuul/fetch
```
@clarkb:matrix.orgthanks I think that confirms what I just found too so  ya we need to add another test but then this code should be well covered22:40
@vlotorev:matrix.org * corvus: here are logs for repo cloned from gerrit and for repo fetched from CI node:22:42
```
$ cat sandbox/.git/packed-refs
# pack-refs with: peeled fully-peeled sorted
f14249f65247fa8ae273d52a185c8f3afae45a28 refs/remotes/origin/master
24d70188aae833bb4fd43f16cb6f5cde3392e7f4 refs/tags/0.1
^f14249f65247fa8ae273d52a185c8f3afae45a28
$ cat zuul-sandbox/.git/packed-refs
# pack-refs with: peeled fully-peeled sorted
db62e3c9bbebb7e77dead2009eea3922832faade refs/heads/master
f14249f65247fa8ae273d52a185c8f3afae45a28 refs/remotes/origin/master
24d70188aae833bb4fd43f16cb6f5cde3392e7f4 refs/tags/0.1
db62e3c9bbebb7e77dead2009eea3922832faade refs/zuul/4f26aeafdb2367620a393c973eddbe8f8b846ebd
db62e3c9bbebb7e77dead2009eea3922832faade refs/zuul/fetch
```
@jim:acmegating.comas for timing, i created a repo with 10k signed tags, and it takes 0.0923 seconds to do an odb.info on all of them.  if i add a repo.commit() that increases to 0.5810365611687303.  so it is considerably more work, though it may be acceptable; the alternative would be a significant increase in the repo state size.22:42
@jim:acmegating.com * as for timing, i created a repo with 10k signed tags, and it takes 0.0923 seconds to do an odb.info on all of them.  if i add a repo.commit() that increases to 0.5810.  so it is considerably more work, though it may be acceptable; the alternative would be a significant increase in the repo state size.22:43
@jim:acmegating.com(i checked, and unfortunately, odb.info doesn't have the commit info22:43
@jim:acmegating.comClark: lol, repo.commit() calls rev_parse, and somehow adds lots of runtime22:45
@clarkb:matrix.orgoh should we be using rev_parse?22:45
@jim:acmegating.comyeah, but lemme check real quick if there's an odb method that will get it for us22:46
@clarkb:matrix.orgI've foudn a test that appears to run against a regular tag. I think I can cobble something together based on that that works with an annotated tag22:46
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 914729: Optimize the merger tag sha translation https://review.opendev.org/c/zuul/zuul/+/91472923:09
@jim:acmegating.comClark: ^ that's as optimized as i can get it.  i tried using the odb methods directly, but no change in runtime.  that gets us 0.2258 seconds in my test.   we could achieve most of that with rev_parse as well, that's like 0.25 or 0.26; but this saves a little bit of processing.23:10
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 914729: Optimize the merger tag sha translation https://review.opendev.org/c/zuul/zuul/+/91472923:13
@clarkb:matrix.orgok that actually looks really similar to what I ended up with rev_parse. Should I take your change and squash it into mine adding in the updated testing?23:14
@jim:acmegating.comyeah, feel free; mostly did it as a followup to avoid collision23:17
@clarkb:matrix.orgcorvus: `git.Object.new_from_sha(repo, binsha)` feels like a huge departure from the repo api, btu I can't find anything like `repo.create_object_from_sha` so I'll live with it23:25
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 914715: Handle annotated and signed tags when packing refs https://review.opendev.org/c/zuul/zuul/+/91471523:25
-@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 914715: Handle annotated and signed tags when packing refs https://review.opendev.org/c/zuul/zuul/+/91471523:26

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!