#8 New message type for "name-version".
Merged 5 years ago by ralph. Opened 5 years ago by ralph.
fedora-ci/ ralph/messages name-version  into  master

@@ -0,0 +1,30 @@ 

+ {

+   "ci": {

+     "name": "PELC",

+     "team": "PELC",

+     "url": "https://somewhere.com",

+     "irc": "#pelc",

+     "email": "pelc@somewhere.com",

+     "environment": "production"

+   },

+   "run": {

+     "url": "https://pelc.somewhere.com/reviews/4794",

+     "log": "https://pelc.somewhere.com/reviews/4794",

+     "rebuild": "https://pelc.somewhere.com/reviews/4794"

+   },

+   "artifact": {

+     "type": "component-version",

+     "component": "389-ds-base",

+     "version": "1.4.0.10",

+     "id": 16678200,

+     "issuer": "mareynol",

+     "nvr": "389-ds-base-1.4.0.10-1.fc28",

+     "source": "git+https://src.fedoraproject.org/rpms/389-ds-base.git?#37939febb"

+   },

+   "type": "review",

+   "category": "validation",

+   "status": "passed",

+   "namespace": "pelc",

+   "generated_at": "2018-09-07 00:59:01.123602",

+   "version": "0.1.0"

+ }

@@ -0,0 +1,30 @@ 

+ {

+   "ci": {

+     "name": "PELC",

+     "team": "PELC",

+     "url": "https://somewhere.com",

+     "irc": "#pelc",

+     "email": "pelc@somewhere.com",

+     "environment": "production"

+   },

+   "run": {

+     "url": "https://pelc.somewhere.com/reviews/4794",

+     "log": "https://pelc.somewhere.com/reviews/4794",

+     "rebuild": "https://pelc.somewhere.com/reviews/4794"

+   },

+   "artifact": {

+     "type": "component-version",

+     "component": "389-ds-base",

+     "version": "1.4.0.10",

+     "id": 16678200,

+     "issuer": "mareynol",

+     "nvr": "389-ds-base-1.4.0.10-1.fc28",

+     "source": "git+https://src.fedoraproject.org/rpms/389-ds-base.git?#37939febb"

+   },

+   "type": "review",

+   "category": "validation",

+   "reason": "PELC internal error - details",

+   "namespace": "pelc",

+   "generated_at": "2018-05-10 08:58:31.222602",

+   "version": "0.1.0"

+ }

@@ -0,0 +1,28 @@ 

+ {

+   "ci": {

+     "name": "PELC",

+     "team": "PELC",

+     "url": "https://somewhere.com",

+     "irc": "#pelc",

+     "email": "pelc@somewhere.com",

+     "environment": "production"

+   },

+   "run": {

+     "url": "https://pelc.somewhere.com/reviews/4794",

+     "log": "https://pelc.somewhere.com/reviews/4794"

+   },

+   "artifact": {

+     "type": "component-version",

+     "component": "389-ds-base",

+     "version": "1.4.0.10",

+     "id": 16678200,

+     "issuer": "mareynol",

+     "nvr": "389-ds-base-1.4.0.10-1.fc28",

+     "source": "git+https://src.fedoraproject.org/rpms/389-ds-base.git?#37939febb"

+   },

+   "type": "scan",

+   "category": "validation",

+   "namespace": "pelc",

+   "generated_at": "2018-05-10 08:58:31.222602",

+   "version": "0.1.0"

+ }

@@ -0,0 +1,28 @@ 

+ {

+   "ci": {

+     "name": "PELC",

+     "team": "PELC",

+     "url": "https://somewhere.com",

+     "irc": "#pelc",

+     "email": "pelc@somewhere.com",

+     "environment": "production"

+   },

+   "run": {

+     "url": "https://pelc.somewhere.com/reviews/4794",

+     "log": "https://pelc.somewhere.com/reviews/4794"

+   },

+   "artifact": {

+     "type": "component-version",

+     "component": "389-ds-base",

+     "version": "1.4.0.10",

+     "id": 16678200,

+     "issuer": "mareynol",

+     "nvr": "389-ds-base-1.4.0.10-1.fc28",

+     "source": "git+https://src.fedoraproject.org/rpms/389-ds-base.git?#37939febb"

+   },

+   "type": "scan",

+   "category": "validation",

+   "namespace": "pelc",

+   "generated_at": "2018-05-10 08:58:31.222602",

+   "version": "0.1.0"

+ }

@@ -0,0 +1,51 @@ 

+ $id: https://pagure.io/fedora-ci/messages/component-version.test.complete

+ $schema: http://json-schema.org/draft-07/schema#

+ 

+ description:

+     Testing of a version of a package has been completed.

+     This is a mandatory message.

+ 

+ properties:

+     ci:

+         $ref: ci.json

+     run:

+         $ref: run.json

+     artifact:

+         $ref: component-version.json

+     category:

+         $ref: common.json#properties/category

+     type:

+         $ref: common.json#properties/type

+     label:

+         $ref: common.json#properties/label

+     status:

+         $ref: common.json#properties/status

+     web_url:

+         $ref: common.json#properties/web_url

+     xunit:

+         $ref: common.json#properties/xunit

+     recipients:

+         $ref: common.json#properties/recipients

+     thread_id:

+         $ref: common.json#properties/thread_id

+     namespace:

+         $ref: common.json#properties/namespace

+     note:

+         $ref: common.json#properties/note

+     generated_at:

+         $ref: common.json#properties/generated_at

+     version:

+         $ref: common.json#properties/version

+ 

+ required:

+     - ci

+     - run

+     - artifact

+     - type

+     - category

+     - status

+     - namespace

+     - generated_at

+     - version

+ 

+ type: object

@@ -0,0 +1,50 @@ 

+ $id: https://pagure.io/fedora-ci/messages/component-version.test.error

+ $schema: http://json-schema.org/draft-07/schema#

+ 

+ description:

+     Testing has aborted, it was not finished, e.g. because of infrastructure

+     error, CI system error, etc. Note that a test failure is not an error.

+     Test failures should be exposed under the component-version.test.error topic.

+     This is a mandatory message.

+ 

+ properties:

+     ci:

+         $ref: ci.json

+     run:

+         $ref: run.json

+     artifact:

+         $ref: component-version.json

+     category:

+         $ref: common.json#properties/category

+     type:

+         $ref: common.json#properties/type

+     label:

+         $ref: common.json#properties/label

+     reason:

+         $ref: common.json#properties/reason

+     issue_url:

+         $ref: common.json#properties/issue_url

+     recipients:

+         $ref: common.json#properties/recipients

+     thread_id:

+         $ref: common.json#properties/thread_id

+     namespace:

+         $ref: common.json#properties/namespace

+     note:

+         $ref: common.json#properties/note

+     generated_at:

+         $ref: common.json#properties/generated_at

+     version:

+         $ref: common.json#properties/version

+ 

+ required:

+     - ci

+     - run

+     - artifact

+     - type

+     - category

+     - namespace

+     - reason

+     - generated_at

+ 

+ type: object

@@ -0,0 +1,41 @@ 

+ $id: https://pagure.io/fedora-ci/messages/component-version.test.queued

+ $schema: http://json-schema.org/draft-07/schema#

+ 

+ description:

+     Testing has been queued, but not yet started.

+     This is an optional message.

+ 

+ properties:

+     ci:

+         $ref: ci.json

+     run:

+         $ref: run.json

+     artifact:

+         $ref: component-version.json

+     category:

+         $ref: common.json#properties/category

+     type:

+         $ref: common.json#properties/type

+     label:

+         $ref: common.json#properties/label

+     thread_id:

+         $ref: common.json#properties/thread_id

+     namespace:

+         $ref: common.json#properties/namespace

+     note:

+         $ref: common.json#properties/note

+     generated_at:

+         $ref: common.json#properties/generated_at

+     version:

+         $ref: common.json#properties/version

+ 

+ required:

+     - ci

+     - run

+     - artifact

+     - type

+     - category

+     - namespace

+     - generated_at

+ 

+ type: object

@@ -0,0 +1,43 @@ 

+ $id: https://pagure.io/fedora-ci/messages/component-version.test.running

+ $schema: http://json-schema.org/draft-07/schema#

+ 

+ description:

+     Testing has been started and is in progress.

+     This is an optional message.

+ 

+ properties:

+     ci:

+         $ref: ci.json

+     run:

+         $ref: run.json

+     artifact:

+         $ref: component-version.json

+     category:

+         $ref: common.json#properties/category

+     type:

+         $ref: common.json#properties/type

+     label:

+         $ref: common.json#properties/label

+     lifetime:

+         $ref: common.json#properties/lifetime

+     thread_id:

+         $ref: common.json#properties/thread_id

+     namespace:

+         $ref: common.json#properties/namespace

+     note:

+         $ref: common.json#properties/note

+     generated_at:

+         $ref: common.json#properties/generated_at

+     version:

+         $ref: common.json#properties/version

+ 

+ required:

+     - ci

+     - run

+     - artifact

+     - type

+     - category

+     - namespace

+     - generated_at

+ 

+ type: object

@@ -0,0 +1,65 @@ 

+ $id: https://pagure.io/fedora-ci/messages/component-version

+ $schema: http://json-schema.org/draft-07/schema#

+ 

+ description:

+     Details about a version of a package being tested.

+ 

+ properties:

+     type:

+         description:

+             Artifact type, in this case 'component-version'.

+         enum:

+             - component-version

+         type: string

+     component:

+         description:

+             Name of the component tested.

+         examples:

+             - bash

+             - python

+             - firefox

+         type: string

+     version:

+         description:

+             Version of the component tested.

+         examples:

+             - 1.2.3

+             - 10.9.0

+             - 20180907

+         type: string

+     id:

+         description:

+             Task ID of the koji build on which the test was performed, optional.

+         examples:

+             - 14546276

+         type: integer

+     issuer:

+         description:

+             Build issuer of the artifact on which the test was performed, optional.

+         examples:

+             - ovasik

+         type: string

+     nvr:

+         description:

+             Name-version-release of the artifact on which the test was performed, optional.

+         examples:

+             - setup-2.8.71-7.el7_4

+         type: string

+     source:

+         description:

+             The first item in the request field from task details. This is

+             usually a link to git repository with a reference, delimited with

+             the '#' sign. In case of a scratch build or other build built via

+             uploading a src.rpm the build task source will look like the bash

+             scratch build.  Optional.

+         examples:

+             - git+https://src.fedoraproject.org/rpms/setup.git?#5e0ae23a

+             - cli-build/1498396792.492652.jYJCrkUF/bash-4.4.12-5.fc26.src.rpm

+         type: string

+ 

+ required:

+     - type

+     - component

+     - version

+ 

+ type: object

We want to use this for an internal tool called PELC. Some context: an
automatic scan (pelc.validation.scan) and a review (pelc.validation.review) are
performed. The results of these operations should be considered valid until
the next rebase, which leads us to the introduction of this new result type:
(name, version).

A result for a rpm NVR should be considered relevant to all future NVRs that
differ in the release field only. As soon as the version field increases, new
results are needed for the package in question.

Should we set environment as 'production' always or we should choose production/stage/qe/dev for difficult instance accordingly?

PELC autojob/human review is not a jenkins job, so does provide organized log on UI, will confirm with team how to fill out this entry.
May be just pose same one with url.

Double confirm, here the 'generated_at' means message publishing time, correct?

Here the status can be [PASSED, INFO, NEEDS_INSPECTION].
FAILED is covered by name-version.test.error.json when something wrong with PELC, like internal error, right?
How about NOT_APPLICABLE?

/topic/VirtualTopic.eng.ci.name-version.test.{queued,running,complete,error} looks good, for NOT_APPLICABLE, see my another comment above.
I am thinking if we should add more information for artifact, like issuer, nrv, id, scratch, source,and others. The primary consumers are ET and Greenwave, want to hear ideas from them.
For ET, if want to get a proper pelc report for a build, may also want product_verison/product_release.
For ET/GreenWave, concerning modules, I am thinking if pelc should publish special info to make ET/Greenwave are convenient to know a bundle of reviews are belong to a module.

For contacts, like reviewers, job requester, I am not sure if factory is designed to store them to make notifications to them with special perpose.

Yes, please set the value to production or stage or dev depending on which message bus environment you send it to.

Yeah, re-using the same url works for me. :)

@ralph hmm I added a comment and pagure somehow did not save it seems :(

I had just one thought, would not make more sense to call the artifact "component-version" ? The "name-version" sounds too generic to me. looking @ PELC, it is just about packages/components.

Ah, this is a point of confusion. @mvadkert, please correct me if I'm wrong.

The foo.test.error topic is supposed to be sent when the test system (pelc in this case) fails due to an infrastructure issue or some other system fault.

If the test-running system (pelc, in this case) is operating normally but the test itself fails (because the content didn't pass the test), then the foo.test.complete topic should be sent, but with a failed value in the status field. The test completed with an outcome of failure.

FYI, if I modify the examples/name-version.test.complete.json file to use not_applicable instead of passed, the schema still accepts it. See:

λ git diff
diff --git a/examples/name-version.test.complete.json b/examples/name-version.test.complete.json
index 8d50d16..ccc4ecf 100644
--- a/examples/name-version.test.complete.json
+++ b/examples/name-version.test.complete.json
@@ -19,7 +19,7 @@
   },
   "type": "review",
   "category": "validation",
-  "status": "passed",
+  "status": "not_applicable",
   "namespace": "pelc",
   "generated_at": "2018-09-07 00:59:01.123602",
   "version": "0.1.0"

λ make convert && ./scripts/validate.py schemas/name-version.test.complete.json examples/name-version.test.complete.json
make: Nothing to be done for 'convert'.
Validation successful.

I'm fine renaming this to component-version. :) Will do it shortly.

1 new commit added

  • Rename things to component-version.
5 years ago

OK, I made the component-version change.

To Yaobin's points:

/topic/VirtualTopic.eng.ci.name-version.test.{queued,running,complete,error} looks good, for NOT_APPLICABLE, see my another comment above.

Yeah, as above - I think there's one confusing thing to clear up: the /topic/VirtualTopic.eng.ci.component-version.test.complete topic should be used for all the passed and the failed and the not_applicable status. The /topic/VirtualTopic.eng.ci.component-version.test.error should only be used when pelc itself fails to do its job.

I am thinking if we should add more information for artifact, like issuer, nrv, id, scratch, source,and others. The primary consumers are ET and Greenwave, want to hear ideas from them.

Yeah, if PELC can provide this. I'll add it to the spec and examples. I don't think they should be required for all component-version result producers, but if PELC can provide them then that's great.

For ET, if want to get a proper pelc report for a build, may also want product_verison/product_release.

We can include those as well, but I'll make them optional in case of other systems that want to produce component-version results but which don't know anything about product_version or product_release.

For ET/GreenWave, concerning modules, I am thinking if pelc should publish special info to make ET/Greenwave are convenient to know a bundle of reviews are belong to a module.

Hm, the design we'd agreed on previously with Simon and Jason was that most test tools shouldn't have to know that content in a module is in a module. If PELC can just report on the pieces, ET will know that the pieces are tied together and can aggregate as it needs to.

For contacts, like reviewers, job requester, I am not sure if factory is designed to store them to make notifications to them with special perpose.

No, no use for those or plan for those at the moment in the DevOps side of the factory.

1 new commit added

  • Add some optional fields for the component-version artifact.
5 years ago

@ralph Thanks for your answers.
Sorry, I am not used to the workflow way to leave comments, or as I am not familiar with how to use pagure, so will not response all your replies one by one, if did not mentioned them again, that means, I got answers, Thanks.

PELC may want to publish additional information which are optional for other systems. Which additional information? I will double confirm with team, as we should make sure if any teams/tools who do not costume PELC data through factory/ET and want to grab PELC's messages directly to do something . So, feel free to merge this MR, the current message definition is good to me. Thanks.

@ralph Ah, this is a point of confusion. @mvadkert, please correct me if I'm wrong. The foo.test.error topic is supposed to be sent when the test system (pelc in this case) fails due to an infrastructure issue or some other system fault. If the test-running system (pelc, in this case) is operating normally but the test itself fails (because the content didn't pass the test), then the foo.test.complete topic should be sent, but with a failed value in the status field. The test completed with an outcome of failure.

That is correct, error should be used only if the process (in this case test) was not successfully finished. This usually means the CI system raised an error during this.

A result for a rpm NVR should be considered relevant to all future NVRs that
differ in the release field only. As soon as the version field increases, new
results are needed for the package in question.

Today I thought over it though It is not about message format, the statement are saying 2 things from side,
1) will not schedule a new pelc job for only release change(NV is same)
2) Which PELC report ET will get from factory for release change(NV is same)

  • as PELC treat all content in source rpm as source files to scan, so just care NV only means ignore patches.
  • some packages bump release with different tarballs(like a new version) also, they do not follow rpm build policy well.

is it possible get PELC do not scan and review the duplicated one? at least review only the delta portion, but the report will be baseline+delta.

From me no other comments and +1

PELC may want to publish additional information which are optional for other systems. Which additional information? I will double confirm with team, as we should make sure if any teams/tools who do not costume PELC data through factory/ET and want to grab PELC's messages directly to do something . So, feel free to merge this MR, the current message definition is good to me. Thanks.

Yes. I think it is fine for PELC to add additional information to the message, so long as the message at least provides the fields and values from the spec here. @yaobin, in PELC development, please try to use the validation script provided by this repo as part of the integration test suite of PELC to be sure that the messages produced really do conform to what is specified here (we've never done that before, but it will be great if we can machine-verify the messages in PELC's test suite).

To the question about duplicates, I think it is fine if PELC scans or reviews happen multiple times for the same (component, version) if there are new nvrs. The new results (the latest ones) will take precedence in greenwave and ET's considerations.

Pull-Request has been merged by ralph

5 years ago

Note: In order to be able to share system/team contact information between test messages and gate messages (or other future types) we've moved ci.yaml to contact.yaml with a slight change in the list of required fields: docs link is required while url is optional:

I've adjusted relevant component-version files as well:

Please have a look and make sure everything's ok. Thanks.

in PELC development, please try to use the validation script provided by this repo as part of the integration test suite of PELC to be sure that the messages produced really do conform to what is specified here (we've never done that before, but it will be great if we can machine-verify the messages in PELC's test suite).

We will, Thanks.

To Rename "ci" schema to "contact", looks good to me.