Add a new event for deployed artifacts

t-persson commented 2 years ago

Applicable Issues

fixes: #239

Description of the Change

Added a minimal version of an Artifact Deployed event. This is not yet ready and will need some revisions to get right, but it is a discussion point. Also a link from EiffelConfidenceLevelModifiedEvent to this new event. Can be removed if we want.

Alternate Designs

There have been lengthy discussions, somewhat documented in #239 but we decided that in order to start with deployment we should not focus on operations but just getting the ball rolling. This will be the first 0.0.X event that we've introduced. Done so because we want to be clear that this is experimental.

Benefits

We'll have something to start testing deployment events with.

Possible Drawbacks

If we are not clear that this is experimental, then some users may be confused or angry when things change.

Sign-off

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

Signed-off-by: Tobias Persson tobias.persson@axis.com

e-backmark-ericsson commented 2 years ago

I miss the ArtifactDeployedEvent link in the ToC README.md. And also this example file that is linked from the new ArtD md page: examples/events/EiffelArtifactDeployedEvent/simple.json

t-persson commented 2 years ago

I miss the ArtifactDeployedEvent link in the ToC README.md. And also this example file that is linked from the new ArtD md page: examples/events/EiffelArtifactDeployedEvent/simple.json

By design. Just want reviews on the actual event structure first, before adding examples etc.

e-backmark-ericsson commented 1 year ago

From discussion on community meeting on Dec 8th:

Entry in the top README.md TOC is missing
Add optional data.description (string) with description "Any human readable information about this deployment"
For the CONFIGURATION link type, expand the description with an example stating Helm chart as a kind of artifact to link to. See Magnus comment above.
Has been discussed, but not valid for now: For "previous" deployments of the same artifact (same ArtC event id) in the same environment, we want to have a PREVIOUS_DEPLOYMENT link type

e-backmark-ericsson commented 1 year ago

Additional comment from community meeting:

Add legal target to deployment event on IUT links from IV and TCT.

e-backmark-ericsson commented 1 year ago

With the changes requested from Magnus implemented, this PR looks good to me.

jdartland commented 1 year ago

At the last community meeting we discussed that ”Setting a subject link of an CLM to point to CD means that we have reached a confidence on a recipe containing software artifacts”.

If a CD grouping artifacts is seen as a recipe, and a ArtD would be a instantiation of such a recipe. Then It would be great to directly point to “the recipie” (a CD with all artifacts) with a single ArtD by the ARTIFACT link. Rather than having to create an ArtD for every single artifact in the “recipie”. Thoughts?

magnusbaeck commented 1 year ago

Sorry for dropping the ball here, @jdartland. I believe we at some point discussed the possibility of linking ArtD to either a CD that groups artifacts or allowing the ArtD to have multiple outbound ARTIFACT links, but IIRC those options were rejected because ArtD describes the deployment of a single artifact. One can certainly deploy multiple artifacts at the same time, but it's not clear that those represent the same deployment.

I could probably be persuaded otherwise with the right motivation. I suppose one counter argument could be that a single ArtD that (directly or indirectly) links to multiple ArtC is useful in the sense that it's clear that the artifacts are deployed together, e.g. with the same deployment command (and the same ArtC in the CONFIGURATION link, if present). On the other hand, I wonder if that rather should be described by wrapping all ArtDs in activity.

magnusbaeck commented 1 year ago

Gah, I didn't note that another rebase was necessary. I've updated the artd branch in my fork. @t-persson, can you please push that to your PR branch? This is what the diff against master looks now:

--- definitions/EiffelConfidenceLevelModifiedEvent/3.2.0.yml    2022-11-11 14:54:30.932509893 +0100
+++ definitions/EiffelConfidenceLevelModifiedEvent/3.3.0.yml    2023-05-26 15:44:05.899196509 +0200
@@ -122,6 +122,7 @@
       any_type: false
       types:
         - EiffelArtifactCreatedEvent
+        - EiffelArtifactDeployedEvent
         - EiffelCompositionDefinedEvent
         - EiffelSourceChangeCreatedEvent
         - EiffelSourceChangeSubmittedEvent
@@ -139,6 +140,11 @@
       types:
         - EiffelConfidenceLevelModifiedEvent
 _history:
+  - version: 3.3.0
+    introduced_in: No edition set
+    changes: Add EiffelArtifactDeployedEvent as legal target type for
+      SUBJECT link (see
+      [Issue 239](https://github.com/eiffel-community/eiffel/issues/239)).
   - version: 3.2.0
     introduced_in: '[edition-arica](../../../tree/edition-arica)'
     changes: Add schema URL to the meta object (see [Issue 280](https://github.com/eiffel-community/eiffel/issues/280)).
--- schemas/EiffelConfidenceLevelModifiedEvent/3.2.0.json   2023-05-26 16:01:43.314931012 +0200
+++ schemas/EiffelConfidenceLevelModifiedEvent/3.3.0.json   2023-05-26 16:01:43.370930786 +0200
@@ -18,9 +18,9 @@
         "version": {
           "type": "string",
           "enum": [
-            "3.2.0"
+            "3.3.0"
           ],
-          "default": "3.2.0"
+          "default": "3.3.0"
         },
         "time": {
           "type": "integer"
--- definitions/EiffelIssueVerifiedEvent/4.2.0.yml  2022-11-11 14:54:55.536440959 +0100
+++ definitions/EiffelIssueVerifiedEvent/4.3.0.yml  2023-05-26 15:44:05.899196509 +0200
@@ -1,4 +1,4 @@
-# Copyright 2017-2022 Ericsson AB and others.
+# Copyright 2017-2023 Ericsson AB and others.
 # For a full list of individual contributors, please see the commit history.
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
@@ -108,6 +108,7 @@
       any_type: false
       types:
         - EiffelArtifactCreatedEvent
+        - EiffelArtifactDeployedEvent
         - EiffelCompositionDefinedEvent
   SUCCESSFUL_ISSUE:
     description: Identifies an issue that has been successfully verified.
@@ -128,6 +129,9 @@
         - EiffelTestCaseFinishedEvent
         - EiffelTestSuiteFinishedEvent
 _history:
+  - version: 4.3.0
+    introduced_in: No edition set
+    changes: Add artifact deployed event as legal IUT target (see [Issue 239](https://github.com/eiffel-community/eiffel/issues/239)).
   - version: 4.2.0
     introduced_in: '[edition-arica](../../../tree/edition-arica)'
     changes: Add schema URL to the meta object (see [Issue 280](https://github.com/eiffel-community/eiffel/issues/280)).
--- schemas/EiffelIssueVerifiedEvent/4.2.0.json 2023-05-26 16:01:44.622925737 +0200
+++ schemas/EiffelIssueVerifiedEvent/4.3.0.json 2023-05-26 16:01:44.678925510 +0200
@@ -18,9 +18,9 @@
         "version": {
           "type": "string",
           "enum": [
-            "4.2.0"
+            "4.3.0"
           ],
-          "default": "4.2.0"
+          "default": "4.3.0"
         },
         "time": {
           "type": "integer"
--- definitions/EiffelTestCaseTriggeredEvent/3.3.0.yml  2023-05-26 15:58:59.675591099 +0200
+++ definitions/EiffelTestCaseTriggeredEvent/3.4.0.yml  2023-05-26 16:01:15.579042894 +0200
@@ -170,6 +170,7 @@
       any_type: false
       types:
         - EiffelArtifactCreatedEvent
+        - EiffelArtifactDeployedEvent
         - EiffelCompositionDefinedEvent
         - EiffelSourceChangeCreatedEvent
         - EiffelSourceChangeSubmittedEvent
@@ -188,8 +189,11 @@
       types:
         - EiffelTestCaseTriggeredEvent
 _history:
+  - version: 3.4.0
+    introduced_in: No edition set
+    changes: Add artifact deployed event as legal IUT target (see [Issue 239](https://github.com/eiffel-community/eiffel/issues/239)).
   - version: 3.3.0
-    introduced_in: Current version
+    introduced_in: No edition set
     changes: Add SCS and SCC as legal target for IUT in TCT (see [Issue 317](https://github.com/eiffel-community/eiffel/issues/317)).
   - version: 3.2.0
     introduced_in: '[edition-arica](../../../tree/edition-arica)'
--- schemas/EiffelTestCaseTriggeredEvent/3.3.0.json 2023-05-26 16:01:47.102915733 +0200
+++ schemas/EiffelTestCaseTriggeredEvent/3.4.0.json 2023-05-26 16:01:47.170915458 +0200
@@ -18,9 +18,9 @@
         "version": {
           "type": "string",
           "enum": [
-            "3.3.0"
+            "3.4.0"
           ],
-          "default": "3.3.0"
+          "default": "3.4.0"
         },
         "time": {
           "type": "integer"

t-persson commented 1 year ago

Gah, I didn't note that another rebase was necessary. I've updated the artd branch in my fork. @t-persson, can you please push that to your PR branch? This is what the diff against master looks now:

Done

m-linner-ericsson commented 1 year ago

Just remembered that https://github.com/eiffel-community/eiffel/blob/master/eiffel-syntax-and-usage/event-categories.md will not contain the event. Could be that we should have an issue on how to remember to update that page or change it to be generated instead.

magnusbaeck commented 1 year ago

Yes, ArtD should be listed in the category page. I suppose the existing Artifact category would be a reasonable choice?

m-linner-ericsson commented 1 year ago

Yes, ArtD should be listed in the category page. I suppose the existing Artifact category would be a reasonable choice?

Agree, it just to add a line in that table with ArtD.

t-persson commented 1 year ago

Good job everyone. Thanks for the assist with the PR!

eiffel-community / eiffel