support fedmsgs when docker images are built
ClosedPublic

Authored by lbrabec on Sep 15 2016, 3:05 PM.

Details

Summary

After discussion with @jskladan I did some initial hacking on branch feature/rules_engine as we think we should update the upcoming code of new trigger. More code and tests will follow...

When docker image is build, koji produces fedmsg in following format:

"msg": {
                "build_id": 799051,
                "instance": "primary",
                "name": "cockpit",
                "owner": "containerbuild",
                "release": "0.6",
                "tag": "f24-docker",
                "tag_id": 353,
                "user": "containerbuild",
                "version": "0.95"
            },

There is no way to directly tell where to get the image, therefore koji has to be queried, I found the image repository info in archives for given image, it can be obtained with python code:

koji_session.listArchives(799051, type='image')

This query returns:

[{'build_id': 799051, 'type_description': 'Tar files', 'extra': {'image': {'arch': 'x86_64'}, 'docker': {'parent_id': 'sha256:db3bcd639b428283818ea0271fdaa5d1a3c416f11c3e920cdd75cb341e8d653b', 'repositories': ['candidate-registry.fedoraproject.org/fedora/cockpit:0.95-0.6', 'candidate-registry.fedoraproject.org/fedora/cockpit@sha256:e9af81955559007ce0562e8f380ce161622596411b70014786942a0ef84268da'], 'id': '50c728b7bf54fe66aef9577c48069c62aa0a4931434d59f196aaadd029d6a6e4'}}, 'checksum': '4d5615b7a96d11723eea0c9e372dbf01', 'type_name': 'tar', 'filename': 'docker-image-50c728b7bf54fe66aef9577c48069c62aa0a4931434d59f196aaadd029d6a6e4.x86_64.tar.gz', 'buildroot_id': 6376011, 'metadata_only': False, 'type_extensions': 'tar tar.gz tar.bz2 tar.xz', 'type_id': 4, 'checksum_type': 0, 'arch': 'x86_64', 'id': 13564, 'size': 198489144}]

the part we are interested is 'candidate-registry.fedoraproject.org/fedora/cockpit:0.95-0.6' at [0]['extra']['docker']['repositories'][0], but I find this access a little clumsy.

With @kparal, I discussed where do we want to query koji, whether do it in trigger or in task using a koji directive. Kamil is for koji directive, me and Josef are for trigger. The trigger approach can have problem, when the koji is slow, but it produces item in 'docker pullable' format (URL to registry), and compared to directive approach, the koji is queried only once when there are several tasks for given image.
When item is URL to registry, we would need to extract cockpit:0.95-0.6 from the URL, to get 'proper' item name to report against, or start passing more arguments for runtask and be sure that the test is reported against correct nvr.

With the new trigger and this code, the rules for docker images could look like this:

- when: {message_type: KojiBuildDockerCompleted}
  do:
    - {discover: {repo: 'http://pkgs.fedoraproject.org/git/docker-checks/${name}.git', branch: "${distgit_branch}"}}
Test Plan

pytest only atm

Diff Detail

Repository
rTRGR taskotron-trigger
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
lbrabec retitled this revision from to support fedmsgs when docker images are built.Sep 15 2016, 3:05 PM
lbrabec updated this object.
lbrabec edited the test plan for this revision. (Show Details)
lbrabec added reviewers: jskladan, kparal, mkrizek, tflink.
lbrabec set the repository for this revision to rTRGR taskotron-trigger.
lbrabec added a project: taskotron-trigger.
lbrabec added subscribers: kparal, jskladan.
lbrabec updated this revision to Diff 2563.Sep 16 2016, 9:09 AM
lbrabec updated this object.
  • polishing, tests and lint
jskladan requested changes to this revision.Sep 16 2016, 10:57 AM

The idea is sound, overall, I'd just like to see the code be more polished.

jobtriggers/koji_build_msg.py
8–9

Since you moved most of the code to the class, move this method as well.

18–21

I'd rather see one of these two solutions:

  1. rename it to process, and call the _process_XYZ directly (as hinted in the next comments)
  2. move the whole code to consume (and call the _process_XYZ directly).

I don't really see a big gain in having this in a method, that returns a method pointer, so the consume can be "one-liner".

32

Y U no self._process_docker(msg) instead?

37

ditto

testing/test_koji_build_trigger.py
193–253

Copying the whole code, just so you can change one line (221) is the worst way to do it.
I understand that this is probably a proof of concept, but it it stayed, this would be unnecessarily hard to keep in sync.

I'd rather see you modify the _create_msg() so it takes one more argument, that sets the owner to the right value. The _create_msg() is called at the beginning of _most_ of the tests, so adding it to the few that remail would not be that big of a deal.
When you are at it (and although it's not your code per se), please also change the behaviour of the _create_msg() so instead of re-setting the self._ref_message, it returns the generated msg, and the tests use the value as input, instead of the self.ref_message, that currently gets created "as a side effect".

THX.

This revision now requires changes to proceed.Sep 16 2016, 10:57 AM
lbrabec updated this revision to Diff 2565.Sep 16 2016, 11:40 AM
  • code and tests polishing
lbrabec updated this revision to Diff 2566.Sep 16 2016, 11:50 AM
  • changed example

Overall, it looks good to me. One question about finding the dist-git branch, though

jobtriggers/koji_build_msg.py
72

Why is this hardcoded and why is it hardcoded to f24? Can we not get this information for docker image builds?

lbrabec updated this revision to Diff 2567.Sep 16 2016, 2:24 PM
  • koji queries for registry url and tag

I tried running this yesterday and I couldn't get it to work with a fedmsg that came across from a docker layered image build.

Have you all had a chance to test with with incoming fedmsgs? I could easily be mixing something up in the config.

jobtriggers/utils.py
51

This should be configurable but that can be added as a feature request

testing/test_koji_build_trigger.py
106

I don't understand why this was needed

Works for me. I used the default config files, changed the topic to org.fedoraproject.dev.buildsys.build.state.change and tried it with fedmsg replay:

fedmsg-dg-replay --msg-id 2016-e71eff88-1967-4e4c-ad57-0bd1ed5e239b

and at the end of method _process_docker(), variable data contained:

{'item': 'candidate-registry.fedoraproject.org/fedora/cockpit:0.95-0.7', 'version': u'0.95', 'name': u'cockpit', 'distgit_branch': 'f24', 'item_type': 'docker_image', 'release': u'0.7', '_msg': {u'username': u'lbrabec', u'i': 1, u'timestamp': 1474447573, u'msg_id': u'2016-cbbca432-971a-470d-834b-ad0497e0a47e', u'topic': u'org.fedoraproject.dev.buildsys.build.state.change', u'msg': {u'build_id': 802427, u'old': None, u'name': u'cockpit', u'task_id': None, u'attribute': u'state', u'instance': u'primary', u'version': u'0.95', u'owner': u'containerbuild', u'new': 1, u'release': u'0.7'}}, 'message_type': 'KojiBuildDockerCompleted', 'critpath_pkgs': []}

it all ended with exception fatal: repository 'http://pkgs.fedoraproject.org/git/docker-checks/cockpit.git/' not found, which is excepted as the discover part of trigger is not complete.

Huh, I wonder what I set up wrong. Oh well, that's easier to fix than some code issue :)

tflink accepted this revision.Sep 26 2016, 2:21 PM

Let's get this merged in so that testing can start

kparal added inline comments.Oct 12 2016, 12:14 PM
jobtriggers/koji_build_msg.py
40

This seems fragile. You didn't publish the whole fedmsg nor linked to it, but isn't there something like artifact_type: docker somewhere? And if it isn't, shouldn't we request it? Have you talked to mikem/fedora-releng to verify that all docker builds will be always built under containerbuild user?

I'm not saying this needs to change right now, but at least a TODO/FIXME (ideally with a link to a ticket) would be appropriate.

Closed by commit rTRGR5376194b36a5: support fedmsgs when docker images are built (authored by Lukas Brabec <lbrabec@redhat.com>). · Explain WhyOct 14 2016, 8:36 AM
This revision was automatically updated to reflect the committed changes.