├── .github └── CODEOWNERS ├── LICENSE ├── README.md ├── docs ├── facilitator_tasks.md ├── meetings.md ├── meetings_2020.md ├── meetings_2021.md ├── meetings_2022.md ├── pipelines-terminology.md ├── policy_driven_cd.md ├── roadmap.md ├── tools-terminology.md ├── vocabulary.md └── workstream-governance.md └── workstreams └── archived └── events_in_cicd ├── README.md ├── charter.md └── meetings.md /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # These owners will be the default owners for everything in 2 | # the repo. People listed below will be requested for review 3 | # when someone opens a pull request. 4 | * @mjmckay @amfred @e-backmark-ericsson @olivernocon @afrittoli @thedevelopnik @rakhbari @bobcatfish @fdegir @MarckK @zxiiro @tracymiranda @agrimmer @justinabrahms @dsanyika 5 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CDF Interoperability SIG - **Archived** 2 | 3 | The work produced by the Interoperability SIG is available in this repository. 4 | The conversation about interoperability continues at the CDF through the work 5 | of the [CDEvents Project](https://cdevents.dev) and its 6 | [CDEvents Implementation Working Group](https://github.com/cdevents/implementation-wg). 7 | 8 | If you are interested in interoperability please join us at the CDEvents project. 9 | If you would like to resume the work of this SIG, please reach out to the 10 | CDF's [Technical Oversight Committee](https://cd.foundation/about/toc/). 11 | 12 | ## Quick links 13 | 14 | - [CDF Interoperability SIG](#cdf-interoperability-sig) 15 | - [Quick links](#quick-links) 16 | - [Overview](#overview) 17 | - [Members](#members) 18 | - [New Members](#new-members) 19 | - [Governance](#governance) 20 | - [SIG Workstreams](#sig-workstreams) 21 | - [Communication](#communication) 22 | - [Meetings](#meetings) 23 | 24 | ## Overview 25 | 26 | The emergence of new open technologies and methodologies such as cloud native and 27 | microservices has resulted in tremendous advances in various industries and enabled 28 | the rapid development and delivery of new features and services to the end-users 29 | faster than before. Continuous Integration (CI) and Continuous Delivery (CD) are 30 | prerequisites and enablers for organizations to use these technologies and achieve 31 | true agility in response to these changes. 32 | 33 | The organizations that embrace CI/CD employ various tools and technologies depending 34 | on their needs and where they are in their CI/CD transformation. Organizations often 35 | employ more than one tool in various stages of their CI/CD pipelines due to different 36 | capabilities provided by the tools. This is perhaps one of the biggest benefits the 37 | users get by using open technologies for their CI/CD needs. 38 | 39 | However, one of the challenges users face is the lack of interoperability across the 40 | CI/CD tools and technologies, resulting in various issues while constructing and 41 | running pipelines such as passing metadata and artifacts between the tools or achieving 42 | traceability from commit to deployment. Often users end up building "own glue code" to 43 | address what is a common problem, further complicating moving from one tool to another 44 | and adopting new technologies and methodologies. 45 | 46 | These "glue code solutions" are generally specific to users needs and the tools rather 47 | than being loosely coupled and agnostic to tooling and technology. Additionally these 48 | solutions are not visible to other users and the communities, making them vulnerable to 49 | the risks of outage in their CI/CD pipelines due to the potential changes (ie non-backward 50 | changes to the APIs, changes in data models) that happens to the tools in respective 51 | projects. 52 | 53 | SIG Interoperability will focus on addressing these challenges and further work with 54 | projects to achieve a common set of solutions. 55 | 56 | SIG Interoperability aims to enable a dialog in the interoperability area by bringing 57 | CI/CD users together with the open source projects in order to 58 | 59 | * clarify what interoperability means for the CI/CD ecosystem 60 | * promote the need to collaborate on interoperability challenges in a neutral forum 61 | * highlight and promote the needs of the users who face challenges constructing complex 62 | end-to-end CI/CD flows and pipelines by employing different tools and technologies 63 | * explore synergies between, and enable collaboration across, the CI/CD projects with 64 | regards to interoperability 65 | * pursue solutions which are; loosely coupled, scalable, flexible, and tool and 66 | technology agnostic 67 | * reduce the need for users to implement in-house solutions by promoting native 68 | interoperability between tools 69 | * attract and assist projects that work on interoperability 70 | 71 | ## Members 72 | 73 | * Andy Glover ([@aglover](https://github.com/aglover)), Netflix 74 | * Christie Wilson ([@bobcatfish](https://github.com/bobcatfish)), Google 75 | * Eric Sorenson ([@ahpook](https://github.com/ahpook)), Puppet 76 | * Fatih Degirmenci ([@fdegir](https://github.com/fdegir)), CDFoundation 77 | * FuQiao ([@fuqiao123](https://github.com/fuqiao123)), China Mobile 78 | * Kara de la Marck ([@MarckK](https://github.com/MarckK)), Cloudbees 79 | * Priyanka Sharma ([@pritianka](https://github.com/pritianka)), Gitlab 80 | * Thanh Ha ([@zxiiro](https://github.com/zxiiro)), Lumina Networks 81 | * Tracy Miranda ([@tracymiranda](https://github.com/tracymiranda)), Cloudbees 82 | * Wavell Watson ([@wavell](https://github.com/wavell)), Vulk Coop 83 | * Ravi Lachhman ([@ravilach](https://github.com/ravilach)), Harness 84 | * Andreas Grimmer ([@agrimmer](https://github.com/agrimmer)), Dynatrace 85 | * Chun-Hung Hsiao ([@chhsia0](https://github.com/chhsia0)), D2iQ 86 | * Marky Jackson ([@markyjackson](https://github.com/markyjackson-taulia)), OpsMX 87 | * James Rawlings ([@rawlingsj](https://github.com/rawlingsj)), Cloudbees 88 | * Ramin Akhbari ([@rakhbari](https://github.com/rakhbari)), Salesforce 89 | * Cameron Motevasselani ([@link108](https://github.com/link108)), Armory 90 | * Dave Sudia ([@thedevelopnik](https://github.com/thedevelopnik)), GoSpotCheck 91 | * Andrea Frittoli ([@afrittoli](https://github.com/afrittoli)), IBM 92 | * Oliver Nocon ([@olivernocon](https://github.com/olivernocon)), SAP SE 93 | * Emil Bäckmark ([@e-backmark-ericsson](https://github.com/e-backmark-ericsson)), Ericsson 94 | * Vibhav Bobade ([@waveywaves](https://github.com/waveywaves)), Red Hat 95 | * Jerop Kipruto ([@jerop](https://github.com/jerop)), Google 96 | * Saif Ul Islam ([@rubix982](https://github.com/rubix982)), Mapillary 97 | * Ann Marie Fred ([@amfred](https://github.com/amfred)), Red Hat 98 | * Melissa McKay ([@mjmckay](https://github.com/mjmckay)), JFrog 99 | * Justin Abrahms ([@justinabrahms](https://github.com/justinabrahms)), eBay 100 | * Brett Smith ([@xbcsmith](https://github.com/xbcsmith)), SAS Institute Inc. 101 | * Muktesh Mishra ([@mukteshkrmishra](https://github.com/mukteshkrmishra)), Adobe 102 | * Mainak Mitra (@maimitr](https://github.com/maimitr)), Ericsson 103 | 104 | ## New Members 105 | 106 | Membership to SIG Interoperability is open to public and self-declared. 107 | 108 | New members are advised to: 109 | 110 | * Join the [SIG](https://lists.cd.foundation/g/sig-interoperability) and 111 | [CDF TOC](https://lists.cd.foundation/g/cdf-toc) maillists. 112 | * Join the #sig-interoperability channel on [CDF Slack](https://join.slack.com/t/cdeliveryfdn/shared_invite/enQtODM2NDI1NDc0MzIxLTA1MDcxMzUyMGU2NWVlNmQwN2M1N2M4MWJjOWFkM2UzMDY0OWNkNjAzNzM0NzVkNjQ5M2NkMmY2MTRkMWY4MWY) and introduce yourself. 113 | * Go through the [README.md](README.md) document. 114 | * Regularly join the [SIG meetings](docs/meetings.md). 115 | * Submit a PR to add yourself to the [members list](#members). 116 | * Here are various ways to get involved: 117 | * Share your thoughts by joining the meetings or by posting to maillist and Slack channel. 118 | * Add a topic you would like to discuss to [the agenda](docs/meetings.md) of upcoming meeting. 119 | * Create a [new issue](https://github.com/cdfoundation/sig-interoperability/issues) to start gathering feedback and collaborating. 120 | * Choose an issue where [help is needed](https://github.com/cdfoundation/sig-interoperability/issues/labels/help%20wanted) 121 | and comment on it expressing interest. 122 | 123 | ## Governance 124 | 125 | SIG Interoperability is a [CDF Special Interest Group](https://github.com/cdfoundation/toc/tree/master/sigs). 126 | 127 | The process SIG Interoperability follows can be seen from [here](https://github.com/cdfoundation/toc/blob/master/GROUPS.md#sigs). 128 | 129 | Chairs and the TOC Sponsor of the SIG are 130 | 131 | * Melissa McKay ([@mjmckay](https://github.com/mjmckay)), JFrog - Chair 132 | * Dadisi Sanyika ([@dsanyika](https://github.com/dsanyika)), Apple - Chair 133 | * Dan Lorenc ([@dlorenc](https://github.com/dlorenc)), Google - TOC Sponsor 134 | 135 | ## SIG Alumni 136 | 137 | * Fatih Degirmenci, Ericsson Software Technology, 01/2020-03/2022 138 | * Kara de la Marck, CloudBees/CDF, 06/2020-04/2022 139 | * Justin Abrahms, eBay, 04-2022-06/2023 140 | 141 | ### SIG Workstreams 142 | 143 | SIG Interoperability welcomes contributors who take part in the SIG to form workstreams to work on specific areas of interest 144 | in a more focused and structured way. 145 | 146 | Workstream governance is documented [here](./docs/workstream-governance.md). 147 | 148 | Archived workstreams are: 149 | 150 | * [Events in CI/CD](./workstreams/archived/events_in_cicd/README.md): now the [CDF SIG Events](https://github.com/cdfoundation/sig-events/) 151 | 152 | ## Communication 153 | 154 | SIG Interoperability communication happens via a public mailing list and everyone is 155 | welcome to join our open discussions. 156 | 157 | SIG Interoperability also uses Slack for additional collaboration opportunities. 158 | 159 | * Maillist: https://lists.cd.foundation/g/sig-interoperability 160 | * Slack Channel: #sig-interoperability on [CDF Slack](https://cdeliveryfdn.slack.com/join/shared_invite/zt-nwc0jjd0-G65oEpv5ynFfPD5oOX5Ogg#/) 161 | 162 | ## Meetings 163 | 164 | SIG Interoperability meets first and third Thursdays at 15:00UTC. (*See your timezone [here](https://time.is/1500_in_UTC)*). 165 | 166 | * Meeting agenda and minutes: [here](./docs/meetings.md) 167 | * Meeting recordings: [here](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 168 | * Zoom Bridge: [here](https://zoom.us/j/827082528?pwd=RlN5OUZtVVBuZGZRY0NBRnZyZ0NJQT09) 169 | * Zoom International dial-in numbers: [here](https://zoom.us/zoomconference) 170 | * CDF Public Calendar (UTC): [here](https://calendar.google.com/calendar/u/0/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24@group.calendar.google.com&ctz=UTC) 171 | -------------------------------------------------------------------------------- /docs/facilitator_tasks.md: -------------------------------------------------------------------------------- 1 | # SIG Interoperability Meeting Facilitator Responsibilities 2 | 3 | * Craft the agenda before each meeting 4 | * In GitHub Repo: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings.md 5 | * Reach out to people who reserved slot for presentation, confirm they can present, and assist them with any help they need 6 | * https://docs.google.com/document/d/1ZZE-s4OWLJALjs8DNVaBXuS8FruAwuP31d7-lNSD5x8/edit?usp=sharing 7 | * Send out the agenda for the meeting to sig-interoperability maillist at the beginning of the week (generally Mondays) 8 | * Chair the meeting 9 | * Ensure attendance is captured 10 | * Remind people to add their names/organizations 11 | * Add the people who haven’t listed themselves 12 | * Run the meeting based on the agenda 13 | * Agenda bashing - AoB/new topics 14 | * Action Item Review 15 | * Other topics and presentation 16 | * Taking meeting notes on Google Doc during the meeting 17 | * Timekeeping 18 | * Close the meeting 19 | * Remind people when the next meeting is and if there is any presentation scheduled for it 20 | * Get link to video recording from CDF member (usually Dan Lopez), 21 | * Ensure the presentation held during the meeting is uploaded to CDF Presentations repo sig-interoperability folder. 22 | * Commit minutes [from HackMD](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A) to the GitHub repo, thus ensuring HackMD meeting notes and GitHub repo are kept in sync. 23 | * Send minutes to the sig-interoperability@lists.cd.foundation (generally Fridays) 24 | -------------------------------------------------------------------------------- /docs/meetings.md: -------------------------------------------------------------------------------- 1 | ###### tags: `SIG Interoperability` 2 | 3 | # CDF Interoperability SIG Meetings (sig-interoperability) 4 | 5 | [![HacmKD documents](https://hackmd.io/badge.svg)](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A?edit) 6 | 7 | ## Quick links 8 | 9 | * [Logistics](#Logistics) 10 | * [Meeting Recordings](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 11 | * [Agenda and Notes](#Agenda-and-Notes) 12 | * [2023-11-16 Meeting](#November-16-2023) 13 | * 2023-11-02 Meeting (Cancelled) 14 | * [2023-10-05 Meeting](#October-05-2023) 15 | * [2023-09-21 Meeting](#September-21-2023) 16 | * [2023-09-07 Meeting](#September-7-2023) 17 | * [2023-08-17 Meeting](#August-17-2023) 18 | * [2023-08-03 Meeting](#August-3-2023) 19 | * Pause for Summer Break 20 | * [2023-06-15 Meeting](#June-15-2023) 21 | * [2023-06-01 Meeting](#June-1-2023) 22 | * [2023-05-23 Meeting](#May-23-2023) 23 | * [2023-05-18 Meeting](#May-18-2023) 24 | * [2023-05-04 Meeting](#May-4-2023) 25 | * [2023-04-20 Meeting](#April-20-2023) 26 | * [2023-04-06 Meeting](#April-6-2023) 27 | * [2023-03-16 Meeting](#March-16-2023) 28 | * 2023-03-02 Meeting](Cancelled) 29 | * [2023-02-02 Meeting](#February-2-2023)(Cancelled) 30 | * [2023-01-19 Meeting](#January-19-2023) 31 | * 2022-12-15/2023-01-05 Meeting Cancelled for Winter Break 32 | 33 | 34 | ## Logistics 35 | 36 | * **Meeting notes on HackMD.io**: https://hackmd.io/@cdfoundation/ry3TTB5DL 37 | * **When**: First and third Thursdays at [3pm UTC](https://time.is/3pm_in_UTC) during summer time and at [4pm UTC](https://time.is/4pm_in_UTC) during winter time). 38 | * **Zoom Bridge**: https://zoom.us/j/827082528?pwd=RlN5OUZtVVBuZGZRY0NBRnZyZ0NJQT09 39 | * **Zoom International dial-in numbers**: https://zoom.us/zoomconference 40 | * **Meeting Recordings**: [CDF Youtube Channel SIG Interoperability Playlist](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 41 | * **CDF Public Calendar**: [here](https://calendar.google.com/calendar/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24%40group.calendar.google.com&ctz=America%2FLos_Angeles) 42 | * **Past Presentations in CDF Presentations Repository**: https://github.com/cdfoundation/presentations/tree/master/sig-interoperability 43 | * **Presentation Schedule**: https://docs.google.com/document/d/1Owg_I52WEXzqF8g_lX6OTdwbHkH4Z2-7TBA7eCSVMqY/edit 44 | * **2021 Meeting Minutes**: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2021.md 45 | * **2020 Meeting Minutes**: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2020.md 46 | 47 | ## Upcoming Talks 48 | Looking for more! Feel free to suggest ideas in the Interoperability SIG slack channel. 49 | 50 | ## Agenda and Notes 51 | 52 | Meeting agenda and notes are kept on [HackMD.io](https://hackmd.io/@cdfoundation/ry3TTB5DL) where everyone can add new topics to the agenda for upcoming meetings or take notes during the meetings. Please click edit button to edit the document. 53 | 54 | If you are looking for 2021 minutes of meetings, please take a look at [Meetings 2021 document](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2021.md) in SIG Interoperability repository on GitHub. 55 | 56 | ### November 16, 2023 57 | * Melissa McKay, JFrog 58 | * Dadisi Sanyika, Apple 59 | * Fatih Degirmenci, CDF 60 | * Andrea Frittoli, IBM 61 | * ADDME 62 | 63 | #### Agenda & Notes 64 | * Focus Topics 65 | * Whitepaper 66 | * Melissa/Dadisi still need to get together to produce draft 67 | * ACTION: Melissa to begin draft for comment 68 | * Remember to include mention of licensing issues 69 | * Reference Architecture 70 | * Still a work in progress 71 | * Possibly January timeframe for putting something out 72 | * Visualization 73 | * Erikson - grafana based dashboard to visualize events 74 | * repo in CDEvents 75 | * Andrea - KubeCon conversation with [CNOE.io](https://cnoe.io) 76 | * IDP space (backstage portal) 77 | * CDEvents discussion 78 | * Metrics 79 | * Nothing here (YET!) 80 | * Value Stream 81 | * Steve mentioned reaching out to us about collaborating with the Value Stream group 82 | * Plan for next meeting(s) 83 | * Melissa: proposed cancelling Dec 21st and Jan 4th meeting for winter break 84 | * Progress report on open items next meeting on Jan 7th 85 | * Open Disscussion 86 | * Limited time for most of us this time of year 87 | * Interoperability discussions on CDEvents 88 | * Melissa: Ensure we are not overlapping too much with CDEvents SIG; supporting but not closing door to additional ideas that might come up 89 | * Andrea: CDEvents SIG is focused more on technical aspects, support with whitepaper and example ref arch very much needed/appreciated 90 | * Dadisi: CDEvents is "the thing" we currently have to show Interoperability in action, so keeping Interoperability SIG updated and involved is very much relevant and we should continue 91 | 92 | ### November 2, 2023 93 | --CANCELLED-- 94 | 95 | ### October 5, 2023 96 | * Dadisi Sanyika, Apple 97 | * David Custer, Comcast 98 | * ADDME 99 | 100 | #### Agenda & Notes 101 | * Open Discussion 102 | * Comcast interests in joining CDF, Interoperability group 103 | 104 | 105 | ### September 21, 2023 106 | * Dadisi Sanyika, Apple 107 | * Melissa McKay, JFrog 108 | 109 | #### Agenda & Notes 110 | * Focus Topics 111 | * Whitepaper 112 | * Dadisi & Melissa getting together 9/29 113 | * Reference Architecture 114 | * Visualization 115 | * Action Item: Define intent 116 | * Begin to Collect Use Case 117 | * Consider different groups - what's needed 118 | * DevOps 119 | * Developers 120 | * Managers 121 | * Other Business Units 122 | * Metrics 123 | * Value Stream 124 | * Change Management 125 | * Performance 126 | 127 | 128 | ### September 7, 2023 129 | * Dadisi Sanyika, Apple 130 | * Fatih Degirmenci, CDF 131 | 132 | #### Agenda & Notes 133 | * Open Items 134 | * Mission Statement / Outreach / Marketing / Whitepaper 135 | * Roadmap 136 | * Setting more inclusive aspirations 137 | * How to engage with folks new to the CDF 138 | * Near Term 139 | * Interoperability Use Case Primer / Where to get started 140 | * How to get started woth Visualization 141 | * Useful Metrics 142 | * Basic Value Stream 143 | * Mid-term 144 | * Build from what you've learned 145 | * How to DSL discussion 146 | * Increasing Engagement 147 | * Interoperability let's you replace different components 148 | * License changes may impact projects 149 | * Are you competing with the project owner? 150 | * What is the impact of being a vendor using the projects? 151 | * What is the availability alternative solutions? 152 | * This is new to open source 153 | * Fork the project before the change in license 154 | * Foundations represent pre-competetive collaboration 155 | * No risk of the trend 156 | * IP is assigned to the non-profit foundation 157 | * The CLA assigns the copyright to the foundation 158 | * Open Discussion 159 | 160 | 161 | ### August 17, 2023 162 | * Dadisi Sanyika, Apple 163 | * Fatih Degirmenci, CDF 164 | * Damian Curry, NGINX 165 | * ADDME 166 | 167 | #### Agenda & Notes 168 | * Open Items 169 | * Mission Statement 170 | * Roadmap -- https://pbs.twimg.com/media/EDd1avQWsAEVrrz?format=jpg 171 | * Near term 172 | * Visualization 173 | * Metrics 174 | * Basic Value Stream 175 | * How can you contribute immediately 176 | * How to gain a sense of inclusion to the project? 177 | * What can I do to contribute? 178 | * Tell us the problems you have 179 | * Fail fast -- discover what can be done 180 | * Mid-term 181 | * Discovery actionable issue from engagements 182 | * Interoperability DSL 183 | * Future 184 | * Compliance to CDF standards 185 | * Whitepaper 186 | * Dadisi Contribution Update (White Paper) 187 | * Engagement Materials 188 | * Reference Architecture / Paltform Engineering 189 | * [CD Reference Architecture - Capabilities](/A-VRf2cNTOuO_ZULSIb5pQ) 190 | * Supply Chain Topic -- Action Items 191 | * Email SIG Chairs 192 | * Increasing Engagement 193 | * Interoperablity DSL Goals 194 | * Challenges: 195 | * CDEvents is declartive *not* imperative 196 | * Producers emit events *not* consume 197 | * Message Broker or Bus needed 198 | * Interoperability vs Integration 199 | * Security, Identity, Authorization 200 | * What is possible? 201 | * Standardization of core CD processes with adherence to messaging format 202 | * Value Stream Management 203 | * Show the options 204 | * What the baseline 205 | * Where can you progress 206 | * Reference architecture should progress thru small use cases to enterprise 207 | * Show the benefits early in the progression 208 | * Raise the problem space awareness 209 | * Start at the broad problem description 210 | * Create tracks around for the Interoperability topics 211 | * (Alternative) CDF Event/Messaging Bus? 212 | * This can wait 213 | * Open Discussion 214 | 215 | ### August 3, 2023 216 | * Melissa McKay, JFrog 217 | * Dadisi Sanyika, Apple 218 | * Fatih Degirmenci, CDF 219 | * Andrea Frittoli, IBM 220 | * ADDME 221 | 222 | #### Agenda & Notes 223 | 224 | * Welcome back! 225 | * Open items 226 | * Mission Statement/Roadmap 227 | * Whitepaper 228 | * Dadisi waiting on legal approval - revisit next meeting 229 | * Concrete material to share with community & drive engagement 230 | * Interoperability Relaunch Topic Discussion 231 | * Reference Architecture / Platform Engineering 232 | * Good starting point for following topics & for relaunch 233 | * Collect the digital assets and begin! 234 | * app.diagrams.net - Andrea has good starting points 235 | * Reference Architecture Documentation on Best Practices 236 | * https://bestpractices.cd.foundation/architecture/capabilities/ 237 | * Possible identify functional capabilities & diagram 238 | * Other efforts ongoing 239 | * Open SSF 240 | * VSMI 241 | * [CNOE](https://github.com/cnoe-io) 242 | * Andrea: gathering ideas/materials in doc before PTO 243 | * Visualization 244 | * Metrics 245 | * Pipeline DSL 246 | * Risk Management 247 | * Value Stream Management 248 | * Currently driven by SIG Events but has tight relation to overall interoperability area 249 | * Considerations about content: 250 | * Remain holistic 251 | * Set context (org type, different titles) 252 | * Recognize differing needs/requirements 253 | * Start with SOMETHING to get community feedback 254 | * Supply Chain Topic Discussion 255 | * Get email out from current co-chairs about combining groups 256 | * Melissa: contact co-chairs 257 | * Increasing Engagement / Promotion (review ideas from previous meetings) 258 | * Draft email to re-engage/re-introduce the group 259 | * Educate about the Interoperability SIG 260 | * Next meeting - speaker on Interoperability? 261 | * History & accomplishments thus far 262 | * What input are we looking for? give examples for new folks 263 | * Integration vs interoperability 264 | * We have slides for this! Fatih: [KubeCon Road to Interoperability presentation](https://docs.google.com/presentation/d/16t0Fpa5a5Jplc6AQ1OD3jyG290OvtdS-0aSiqeIx5N0/edit?usp=sharing) 265 | * Community outreach 266 | * New marketing material 267 | * Blog 268 | * Write new or reintroduce [blog from 2020](https://cd.foundation/blog/2021/01/19/cdf-sig-interoperability-2020-year-in-review/) 269 | * Individual & CDF social 270 | * Any upcoming speaking events? 271 | * CDF Summit - Spain 272 | * Distribute whitepaper at events 273 | * Badges? 274 | * Regular communication 275 | * Surveys 276 | * Best Practices Workshop? 277 | * Engage Workshop Group 278 | 279 | 280 | 281 | ### June 15, 2023 282 | * Melissa McKay, JFrog 283 | * Dadisi Sanyika, Apple 284 | * Andrea Frittoli, IBM 285 | * ADDME 286 | 287 | #### Agenda & Notes 288 | * Nominations - co-chair announcement 289 | * Congratulations to Dadisi! Melissa: will update mailing list, etc 290 | * Continue discussion on Interoperability mission & roadmap 291 | * Reference Architecture work 292 | * beginning state - possible involvement by NGINX 293 | * Bringing in Supply Chain SIG? 294 | * Focus our resources into a single SIG 295 | * Reserve time for Supply Chain discussion and re-evaluate moving to a separate group if it makes sense 296 | * Relauch Plans (actions prior to Aug 3) 297 | * Dadisi working on writing 298 | * mission statement 299 | * Kubecon submission? 300 | * brainstorm some ideas - CFP closes the 18th 301 | * possible reference architecture submission? (but risky) 302 | * Share with slack & mailing list about relaunch plans, vaca plans, etc 303 | * Setup meeting tomorrow about ref arch 304 | 305 | 306 | ### June 1, 2023 307 | * Melissa McKay, JFrog 308 | * Dadisi Sanyika, Apple 309 | * Fatih Degirmenci, CDF 310 | 311 | #### Agenda & Notes 312 | * Announcement: nomination for new co-chair 313 | * Justin stepping down 314 | * Open nominations 315 | * Vacation plans? Plan for pausing meeting 316 | * We will be pausing in July, so save relaunch efforts for August 317 | * Continue discussion on Interoperability mission & roadmap 318 | * Dadisi and Melissa met on May 23rd to begin this update process 319 | * Platform engineering - is there a better way to bring in tools within existing platforms 320 | * Visualization 321 | * Metrics 322 | * CD Events - linking, attestation 323 | * Continue discussion on how to increase engagement 324 | * Blog 325 | * Write new or reintroduce [blog from 2020](https://cd.foundation/blog/2021/01/19/cdf-sig-interoperability-2020-year-in-review/) 326 | * Community outreach 327 | * Individual social & speaking events 328 | * Reintroduce & educate the Interoperability SIG 329 | * History & accomplishments thus far 330 | * What input are we looking for? give examples for new folks 331 | * Integration vs interoperability 332 | * We have slides for this! Fatih: [KubeCon Road to Interoperability presentation](https://docs.google.com/presentation/d/16t0Fpa5a5Jplc6AQ1OD3jyG290OvtdS-0aSiqeIx5N0/edit?usp=sharing) 333 | * Whitepaper 334 | * Target August 3rd for promotion and relaunch 335 | 336 | 337 | ### May 23, 2023 338 | * Dadisi 339 | * Melissa 340 | 341 | ### Notes - Roadmap Review 342 | * What's the mission of the Interoperability SIG? 343 | * Increase membership 344 | * new marketing material 345 | * draft email to re-engage/re-introduce the group 346 | 347 | * Teaching/Education 348 | * badges 349 | * best practices workshops? 350 | * engage Workshop SIG 351 | 352 | * Pipeline DSL 353 | 354 | 355 | ### May 18, 2023 356 | * Melissa McKay, JFrog 357 | * ADDME 358 | 359 | #### Agenda & Notes 360 | 361 | * Announcements, Updates 362 | * CDCon recap 363 | 364 | * SIG Interoperability Roadmap Review and Update 365 | * Time got away from us at cdCon + GitOpsCon 366 | 367 | * Interoperability Whitepaper 368 | * The work to update the whitepaper is ongoing 369 | 370 | ### May 4, 2023 371 | 372 | #### Participants 373 | * Melissa McKay, JFrog 374 | * Fatih Degirmenci, CDF 375 | * Dadisi Sanyika, Apple 376 | * ADDME 377 | 378 | #### Agenda & Notes 379 | 380 | * TAG App Delivery and CDEvents Collaboration 381 | * A few CDF community members joined the [CNCF TAG App Delivery](https://github.com/cncf/tag-app-delivery) Meeting on May 3rd and discussed potential opportunities to collaborate 382 | * The discussion is still in its early phases but both communities are interested in and excited to collaborate 383 | * One of the initial steps CNCF TAG App Delivery is to update [Pod-tato Head](https://github.com/podtato-head/podtato-head) project to introduce CDEvents there 384 | * The consensus within the group was to reconvene in about a month to continue discussions 385 | * Meeting minutes are available [here](https://docs.google.com/document/d/1OykvqvhSG4AxEdmDMXilrupsX2n1qCSJUWwTc3I7AOs/edit#heading=h.wohj84vlpmok) 386 | * SIG Interoperability Roadmap 387 | * The work to update the roadmap will start during cdCon + GitOpsCon 388 | * Interoperability Whitepaper 389 | * The work to update the whitepaper is ongoing 390 | * Reaching out to others 391 | * Dagger 392 | 393 | #### Action Items 394 | * 395 | 396 | 397 | ### April 20, 2023 398 | 399 | #### Participants 400 | * Melissa McKay, JFrog 401 | * Dadisi Sanyika, Apple 402 | * Victor 403 | 404 | #### Agenda & Notes 405 | 406 | * Sponsorship of the SIG 407 | * Define agenda for upcoming meetings, including speakers we may want to come speak. 408 | * Goals of the SIG this year? 409 | * Research other attempts at this (Surely they exist!) 410 | * Consider Pulumi, Dagger, others? 411 | * ACTION: Dadisi speak with Apple folks 412 | * Get started on CI/CD Specification 413 | * Produce relevant diagrams 414 | * Perhaps focus on CI only first 415 | * Consider an initial implementation(Review [Dagger Recording](https://youtu.be/65WjUohcYEQ?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG&t=400)) 416 | * Work on getting buyin from well known projects 417 | * Complete [whitepaper](https://docs.google.com/document/d/1o5jHbuEQuspwYOruVB4L5-rG8E1wQm5chq8QN7BrrBs/edit#)? 418 | * Dadisi has started on breaking this content up, cleaning it up for a specific audience 419 | * Working with Fatih 420 | 421 | * ACTION ITEMS 422 | * Melissa: cleanup notes, cleanup recording list, basic housekeeping. 423 | 424 | 425 | ### April 6, 2023 426 | 427 | #### Participants 428 | * Melissa McKay, JFrog 429 | * Fatih Degirmenci, CDF 430 | 431 | #### Agenda & Notes 432 | 433 | Moved the following agenda to the next meeting due to time change and low attendance 434 | 435 | * Sponsorship of the SIG 436 | * Define agenda for upcoming meetings, including speakers we may want to come speak. 437 | * Goals of the SIG this year? 438 | * Complete [whitepaper](https://docs.google.com/document/d/1o5jHbuEQuspwYOruVB4L5-rG8E1wQm5chq8QN7BrrBs/edit#)? 439 | 440 | ### March 16, 2023 441 | 442 | #### Participants 443 | * Melissa McKay, JFrog 444 | * ADDME 445 | 446 | #### Agenda & Notes 447 | 448 | * Time Change - due to low attendance, discussed general Interoperability SIG background 449 | 450 | 451 | ### February 2, 2023 452 | 453 | This meeting was cancelled. 454 | Updates on existing action items are deferred to the next meeting on Feb 16. 455 | 456 | 457 | ### January 19, 2023 458 | 459 | #### Participants 460 | * Ramin Akhbari, Salesforce 461 | * Justin Abrahms, eBay 462 | * Melissa McKay, JFrog 463 | * Emil Bäckmark, Ericsson 464 | 465 | 466 | #### Agenda & Notes 467 | 468 | * Announcements! 469 | * CDCon CFP is OPEN 470 | * https://cd.foundation/blog/2023/01/11/cdcon-2023-call-for-papers-now-open/ 471 | * go-scm update 472 | * #go-scm channel in CDF slack 473 | * VSMI update 474 | * [Value Stream Mapping (VSM) Interoperability Technical Committee](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vsmi) 475 | * Andrea met with Helen for an intro 476 | * The orgs that sponsor the VSMI produce software in the are of value management (from feature description to value to users) and they have a big interoperability issue 477 | * their interop group is looking at what exists, especially in open source, to find what where synergies may exists 478 | * There seems to be an overlap with the interop / cdevents missions 479 | * Call scheduled with them next week (24th) to intro the CDF and discuss common goals/missions 480 | * [Whitepaper](https://docs.google.com/document/d/1o5jHbuEQuspwYOruVB4L5-rG8E1wQm5chq8QN7BrrBs/edit#) discussion 481 | * needs an editing pass 482 | * clarify goal - CTA 483 | * purely educational, a description, something else? 484 | * is this a solution looking for a problem? 485 | * REAL examples of times when Interoperability has been a problem are needed 486 | * API section is empty 487 | * Update to current state of the world (CDEvents references) 488 | * What to do with exiting contributors? Rewrite? 489 | * Define agenda for upcoming meetings, including speakers we may want to come speak. 490 | * Goals of the SIG this year? 491 | * Send reminders of meetings with agenda consistently at beginning of the week 492 | * Start a discussion in slack formalizing our goals 493 | * Update on CDEvents 494 | * [testkube.io](https://testkube.io/) is interested in CDEvents 495 | * introduced themselves & presented at CDSummit in Detroit 496 | * https://cdsummit2022.sched.com/event/1BP0p/why-kubernetes-applications-require-a-new-approach-to-testing-using-testkube-bruno-lopes-kubeshop 497 | * contribution to our common Interoperability vocabulary in the context of testing may be valuable 498 | * Follow up 499 | * Melissa - update past presentation SIG documentation: https://docs.google.com/document/d/1Owg_I52WEXzqF8g_lX6OTdwbHkH4Z2-7TBA7eCSVMqY/edit#heading=h.lx7kiadw52fq 500 | * Action Items: 501 | * Melissa: form working group around universal specification for pipeline 502 | * Possible Members: Ramin & other colleagues?, Fatih? 503 | * Justin: discuss with Fatih about primary goal of whitepaper 504 | * Justin/Melissa: continue whitepaper review 505 | * Justin: cleanup/archive our notes 506 | * Andrea: reach out to testkube project to present to Interoperability group 507 | -------------------------------------------------------------------------------- /docs/meetings_2021.md: -------------------------------------------------------------------------------- 1 | ###### tags: `CDF` `SIG Interoperability` 2 | 3 | # CDF Interoperability SIG Meetings 2021 4 | 5 | [![HacmKD documents](https://hackmd.io/badge.svg)](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A?edit) 6 | 7 | ## Note 8 | 9 | This document contains the minutes of the SIG Interoperability meetings held during 2021 and kept for historical/archive purposes. 10 | Please do not edit this document. 11 | 12 | If you are looking for the latest SIG Interoperability minutes of meetings, please head over to [CDF Interoperability SIG Meetings document](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A?view). 13 | 14 | ## Quick links 15 | 16 | * [Logistics](#Logistics) 17 | * [Meeting Recordings](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 18 | * [Agenda and Notes](#Agenda-and-Notes) 19 | * [2021-12-02 Meeting](#December-2-2021) 20 | * [2021-11-18 Meeting](#November-18-2021) 21 | * [2021-10-21 Meeting](#October-21-2021) 22 | * [2021-09-16 Meeting](#September-16-2021) 23 | * [2021-08-05 Meeting](#August-5-2021) 24 | * [2021-06-24 BoF SIG Interoperability](#June-24-2021-SIG-Interoperability-BoF) 25 | * [2021-06-17 Meeting](#June-17-2021) 26 | * [2021-06-03 Meeting](#June-3-2021) 27 | * [2021-05-20 Meeting](#May-20-2021) 28 | * [2021-05-06 Meeting](#May-6-2021) 29 | * [2021-04-15 Meeting](#April-15-2021) 30 | * [2021-04-01 Meeting](#April-1-2021) 31 | * [2021-03-18 Meeting](#March-18-2021) 32 | * [2021-03-04 Meeting](#March-4-2021) 33 | * [2021-02-18 Meeting](#February-18-2021) 34 | * [2021-02-04 Meeting](#February-4-2021) 35 | * [2021-01-21 Meeting](#January-21-2021) 36 | * [2021-01-07 Meeting](#January-7-2021) 37 | 38 | ## Logistics 39 | 40 | * **Meeting notes on HackMD.io**: https://hackmd.io/@cdf-sig-interoperability/ry3TTB5DL 41 | * **When**: First and third Thursdays at 16:00UTC (*See your timezone [here](https://time.is/1600_in_UTC)*). 42 | * **Zoom Bridge**: https://zoom.us/j/827082528?pwd=RlN5OUZtVVBuZGZRY0NBRnZyZ0NJQT09 43 | * **Zoom International dial-in numbers**: https://zoom.us/zoomconference 44 | * **Meeting Recordings**: [CDF Youtube Channel SIG Interoperability Playlist](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 45 | * **CDF Public Calendar**: [here](https://calendar.google.com/calendar/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24%40group.calendar.google.com&ctz=America%2FLos_Angeles) 46 | * **Past Presentations in CDF Presentations Repository**: https://github.com/cdfoundation/presentations/tree/master/sig-interoperability 47 | * **Presentation Schedule**: https://docs.google.com/document/d/1Owg_I52WEXzqF8g_lX6OTdwbHkH4Z2-7TBA7eCSVMqY/edit 48 | * **2020 Meeting Minutes**: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2020.md 49 | 50 | ### December 2, 2021 51 | 52 | #### Participants 53 | * Mattias Linnér, Ericsson 54 | * Oliver Nocon, SAP 55 | * Emil Bäckmark, Ericsson (joined late) 56 | * Jeremy Stanley, OpenDev/Zuul 57 | * Dan Lorenc, Chainguard/Sigstore 58 | * Fatih Degirmenci, Ericsson Software Technology 59 | * \ 60 | 61 | #### Agenda and Notes 62 | * Action Item Review, All 63 | * Updating SIG Interoperability Roadmap, Reminder 64 | * Software Supply Chain 65 | * Standardized Metadata 66 | * Artifact Handling 67 | * Policy Driven CD 68 | * Events 69 | * Link to the document: https://docs.google.com/document/d/1uf3sb-WJUp3Acd3WYL5SvgVECHevonufJOxd6KftOxc/edit# 70 | * Status with interoperability whitepaper, All 71 | * Sigstore Presentation, Dan Lorenc 72 | * Sigstore Website: https://www.sigstore.dev 73 | * \ 74 | 75 | #### Action Items 76 | * ~~Kara + Fatih to update Interoperability SIG Roadmap, starting with the suggestions from Sept 16 meeting~~ 77 | * Kara to see about presentation of SIG work + Roadmap to End User Council, plus potentially have more input from their side. 78 | * Fatih to check the status of whitepaper with Tracy 79 | * \ 80 | 81 | ### November 18, 2021 82 | 83 | #### Participants 84 | * Emil Bäckmark, Ericsson 85 | * Mattias Linnér, Ericsson 86 | * Kara de la Marck, CDF 87 | * \ 88 | 89 | #### Agenda and Notes 90 | * Action Item Review, All 91 | * CISQ SBoM Project, Santiago Torres-Arias 92 | * Started as a project around 2019 to identify tool to tool exchange of SBoMs among pipelines, build tools, etc. 93 | * A lot of SBoMs bits are merged with SPDX 94 | * How to write tooling that could understand SBOM 95 | * Successor of CISQ is SCIM: https://github.com/microsoft/scim 96 | * People involved in CISQ are now involved in other communities like SPDX and SCIM 97 | * Reminder on the new meeting time, All 98 | * 16:00UTC 99 | * Updating SIG Interoperability Roadmap, All 100 | * Software Supply Chain 101 | * Standardized Metadata 102 | * Artifact Handling 103 | * Policy Driven CD 104 | * Events 105 | * Link to the document: https://docs.google.com/document/d/1uf3sb-WJUp3Acd3WYL5SvgVECHevonufJOxd6KftOxc/edit# 106 | * in-toto Presentation, Santiago Torres-Arias 107 | * in-toto website: https://in-toto.io 108 | 109 | #### Action Items 110 | * ~~Matty to start a new discussion on other metadata standardization efforts, more specifically in-toto~~: https://github.com/cdfoundation/sig-interoperability/discussions/74 111 | * ~~Tracy M to find about [CISQ Software Bill of Materials](https://www.it-cisq.org/software-bill-of-materials/)~~ 112 | * Matty to reach out to Kate Stewart 113 | * ~~Fatih to speak with Santiago Torres-Arias~~ 114 | * Kara + Fatih to update Interoperability SIG Roadmap, starting with the suggestions from Sept 16 meeting 115 | * Kara to see about presentation of SIG work + Roadmap to End User Council, plus potentially have more input from their side. 116 | 117 | ### October 21, 2021 118 | 119 | #### Participants 120 | * Ramin Akhbari (eBay) 121 | * Oliver Nocon (SAP) 122 | * Mattias Linnér (Ericsson) 123 | * Kara de la Marck (CDF) 124 | * Fatih Degirmenci (Ericsson Software Technology) 125 | * Emil Bäckmark (Ericsson) 126 | 127 | #### Agenda and Notes 128 | * Action Item Review, All 129 | * DST Ending - Meeting Time Adjustment, All 130 | * Europe@October 31st, NA@November 7th 131 | * Proposal is to move meeting time to 16:00UTC 132 | * This time for the meeting is unanimously acceptable for those on this call. 133 | * Skip meeting on November 4th 134 | * Next meeting is on November 18th 135 | * Fatih to update on his interoperability keynote 136 | * https://www.etsi.org/events/1885-2021-10-8th-ucaat-user-conference-on-advanced-automated-testing 137 | * Spoke on interoperability and this SIG 138 | * Good opportunity to reach out to telecom industry and invite them to CDF and the SIG. 139 | * Hopefully, we will have increased participation and collaboration. 140 | * Reflections from conferences, All 141 | * SupplyChainSecurityCon 142 | * KubeCon CloudNativeCon 143 | * Updating SIG Interoperability Roadmap, All 144 | * Software Supply Chain 145 | * Standardized Metadata 146 | * Artifact Handling 147 | * Policy Driven CD 148 | * Events 149 | * Link to the document: https://docs.google.com/document/d/1uf3sb-WJUp3Acd3WYL5SvgVECHevonufJOxd6KftOxc/edit# 150 | * \ 151 | * All: please review [CDF Landscape site](https://github.com/cdfoundation/cdf-landscape) 152 | * Please add missing projects to the landscape and raise suggestions or comments on the landscape categories. 153 | * [Let's (re)Consider Categories on CDF Landscape](https://github.com/cdfoundation/cdf-landscape/issues/175) 154 | * [Suggested list of projects to add to landscape](https://github.com/cdfoundation/cdf-landscape/issues/123) 155 | * [Project Board for adding additional projects to landscape](https://github.com/cdfoundation/cdf-landscape/projects/1) 156 | * [Ensure all CDF Members represented](https://github.com/cdfoundation/cdf-landscape/issues/147) -- Completed 157 | 158 | #### Action Items 159 | * ~~Matty to start a new discussion on other metadata standardization efforts, more specifically in-toto~~: https://github.com/cdfoundation/sig-interoperability/discussions/74 160 | * Tracy M to find about [CISQ Software Bill of Materials](https://www.it-cisq.org/software-bill-of-materials/) 161 | * Matty to reach out to Kate Stewart 162 | * Fatih to speak with Santiago Torres-Arias 163 | * Kara + Fatih to update Interoperability SIG Roadmap, starting with the suggestions from Sept 16 meeting 164 | * Kara to see about presentation of SIG work + Roadmap to End User Council, plus potentially have more input from their side. 165 | 166 | ### September 16, 2021 167 | 168 | #### Participants 169 | * Kara de la Marck, CloudBees 170 | * Mattias Linnér, Ericsson 171 | * Oliver Nocon, SAP 172 | * Fatih Degirmenci, Ericsson Sotware Technology 173 | * Emil Bäckmark, Ericsson 174 | * Andrea Frittoli, IBM 175 | * Oleg Nenashev, Jenkins 176 | * Matty Noble, AWS 177 | * Shruti Chaturvedi 178 | 179 | #### Agenda and Notes 180 | * Action Item Review, All 181 | * Standardized Metadata, All 182 | * SPDX: 183 | * SPDX Becomes Internationally Recognized Standard for Software Bill of Materials - [announcement](https://www.linuxfoundation.org/press-release/spdx-becomes-internationally-recognized-standard-for-software-bill-of-materials/) 184 | * v3 development is [in progress](https://spdx.github.io/spdx-spec/v3-draft/) 185 | * What could we contribute? 186 | * SPDX SBOM Generator GitHub Action: https://github.com/niravpatel27/gh-action-spdx-sbom-generator 187 | * [in-toto](https://in-toto.io/) 188 | * Jenkins in-toto plugin: https://plugins.jenkins.io/in-toto/ 189 | * Updating [Interoperability SIG Roadmap](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/roadmap.md), All 190 | * Items referring to events in the roadmap can be dropped and we refer to SIG Events instead given that the work is driven there. But this doesn't mean interoperability is not thinking about events. 191 | * Potential new items in the roadmap are 192 | * Supply Chain, SBOM, Standardized Metadata 193 | * Policy Driven CI/CD 194 | * Frameworks/tools/technologies other than CI/CD orchestrators such as build tools (e.g., Shipwright) and test tools (e.g. Junit) and how they relate to interoperability 195 | * [CloudEvents Plugin for Jenkins](https://github.com/jenkinsci/cloudevents-plugin), Shruti Chaturvedi 196 | * [Article on Jenkins Interoperability and the CloudEvents Plugin for Jenkins](https://medium.com/codex/the-what-why-and-how-of-interoperability-and-how-is-jenkins-interoperating-ab68002b663f) 197 | 198 | #### Action Items 199 | * ~~Matty to start a new discussion on other metadata standardization efforts, more specifically in-toto~~: https://github.com/cdfoundation/sig-interoperability/discussions/74 200 | * Tracy M to find about [CISQ Software Bill of Materials](https://www.it-cisq.org/software-bill-of-materials/) 201 | * ~~Fatih D to look at integrating GitHub Discussions to Slack~~ 202 | * Matty to reach out to Kate Stewart 203 | * Fatih to speak with Santiago Torres-Arias 204 | * Kara + Fatih to update Interoperability SIG Roadmap, starting with the suggestions from today's meeting 205 | 206 | ### August 5, 2021 207 | 208 | #### Participants 209 | * Fatih Degirmenci, Ericsson Software Technology 210 | * Mattias Linnér , Ericsson 211 | * Kara de la Marck, CloudBees 212 | * Matty Noble, AWS 213 | * Jeremy Stanley, OpenDev/Zuul 214 | * Saif Ul Islam 215 | * Tracy Miranda, CDF 216 | 217 | #### Agenda and Notes 218 | * Action Item Review, All 219 | * CDF Jenkins-themed Newsletter for September on “Paving the way for Jenkins interoperability in the Cloud”. 220 | * Submissions are open and welcome! 221 | * The articles will be posted on the cd.foundation blog and the best ones will be included in the newsletter. 222 | * Content Deadline: Friday, August 20 223 | * Format: GDoc 224 | * Length: Depends on the type of article, some have more text, some more images, some more code. Trust your judgement. 225 | * Submit here: https://cd.foundation/cdf-blog-submission-form/ 226 | * Recap of cdCon, All 227 | * Questions/comments from BoF 228 | * Metadata standardization 229 | * Why do we need to put effort on interoperability 230 | * Policy 231 | * cdCon Recordings on Youtube: https://www.youtube.com/watch?v=MQU4fKhau1w&list=PL2KXbZ9-EY9TWsV-Jz8ARSt1ko0Yd36ah 232 | * Status of the Interoperability Whitepaper, All 233 | * Whitepaper draft: https://docs.google.com/document/d/1Bgr6EHhW4wUTphU8xyMg87qzSee43PEA_gGdMnPHq9Q/edit 234 | * Standardized Metadata, All 235 | * Pick up where we left off 236 | * The original HackMD document which is now archived: https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ 237 | * Work will continue as GitHub Discussion on SIG Interoperability repo: https://github.com/cdfoundation/sig-interoperability/discussions 238 | * CISQ: https://www.it-cisq.org/software-bill-of-materials/index.htm 239 | * Supply Chain Security 240 | * https://events.linuxfoundation.org/supplychainsecuritycon-north-america/ 241 | * Open Discussion on Next/New Topics, All 242 | * Any topics we should start talking about 243 | * SIG Roadmap: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/roadmap.md 244 | * We may look at the roadmap and see where we are at, what we missed, what we achieved, and refresh/update it accordingly 245 | * Slack GitHub Discussions integration? 246 | * CDF Booth at KubeCon NA 247 | * It may be possible to do the booth duty virtually 248 | * More info/link TBD 249 | * CDF Public Calendar 250 | * https://calendar.google.com/calendar/u/0/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24@group.calendar.google.com&ctz=America/Los_Angeles 251 | 252 | #### Action Items 253 | * ~~Fatih to check with Jennifer Crowley et al to see if BoF schedule can be adjusted to minimize conflicts~~ 254 | * ~~Fatih and Steve to start a discussion around selected area(s)/topic(s) as GitHub discussions~~ 255 | * Candidate is File Information from SPDX Specification: https://spdx.github.io/spdx-spec/4-file-information/ 256 | * Matty to start a new discussion on other metadata standardization efforts, more specifically in-toto 257 | * Tracy M to find about CISQ Software Bill of Materials 258 | 259 | ### June 24, 2021 SIG Interoperability BoF 260 | 261 | #### Agenda and Notes 262 | * Welcome and the format of BoF, Fatih Degirmenci 263 | * Who is who, All 264 | * Integration vs Interoperability and SIG Interoperability, Kara de la Marck 265 | * Both terms used to describe the openness of a system 266 | * Often used synonymously, they have significant differences 267 | * Integration: combining applications to function together. Don't necessarily have common interfaces and often use different data formats. 268 | * This means glue code => hard to maintain, often results in coupling. 269 | * Interoperability: open interfaces, enabling controled and defined access to services from a different application or system. 270 | * If interface is well defined and openly available, then multiple providers can implement the service in a known way and it can be consumed using the defined interface. 271 | * Client A can switch to provider B or C with no failures. 272 | * Well defined, open interfaces enable interoperability by enabling both access and multiple implementations. 273 | * Users have a choice on which implementation to consume and can switch between them with no failures. 274 | * Interoperability in CI/CD context: 275 | * pipeline standardization/languages 276 | * connecting/integrating pipelines 277 | * pipeline data for traceability/visualization 278 | * events in CI/CD 279 | * Open Discussion, All 280 | 281 | ### June 3, 2021 282 | 283 | #### Participants 284 | * Ramin Akhbari (eBay) 285 | * Steve Taylor (DeployHub/Ortelius) 286 | * Kara de la Marck (CloudBees) 287 | * Mattias Linnér (Ericsson) 288 | * Andrea Frittoli (IBM) 289 | * Emil Bäckmark (Ericsson) 290 | * Tracy Ragan (DeployHub/Ortelius) 291 | * Gopinath Rebala (OpsMx) 292 | * Anders Eknert (Styra) 293 | * Fatih Degirmenci (Ericsson Software Technology) 294 | * Jeremy Stanley (OpenDev/Zuul) 295 | 296 | #### Agenda and Notes 297 | * Action Item Review, All 298 | * cdCon SIG Interoperability BoF Session 299 | * June 24, 11:25am EDT: https://sched.co/j07e 300 | * All BoF Sessions: https://cdcon2021.sched.com/overview/type/BoF+Sessions 301 | * SPDX File Information, All 302 | * File information in SPDX Spec: https://spdx.github.io/spdx-spec/4-file-information/ 303 | * Note about the CNCF Operations doc 304 | * The doc is available on: https://github.com/cncf/tag-app-delivery/blob/public-comment/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md 305 | * It is currently under public comment period 306 | * CNCF App Delivery pod tato Head 307 | * https://github.com/cncf/podtato-head 308 | * Open Policy Agent Presentation, Anders Eknert 309 | 310 | #### Action Items 311 | * Fatih to check with Jennifer Crowley et al to see if BoF schedule can be adjusted to minimize conflicts 312 | * Fatih and Steve to start a discussion around selected area(s)/topic(s) as GitHub discussions 313 | * Candidate is File Information from SPDX Specification: https://spdx.github.io/spdx-spec/4-file-information/ 314 | * ~~Fatih to enable GitHub discussions for sig-interoperability repository~~ 315 | * Done: https://github.com/cdfoundation/sig-interoperability/discussions 316 | * ~~Kara to help out reaching out to OPA community~~ 317 | 318 | #### Meeting Recording 319 | * https://www.youtube.com/watch?v=m7Gt_3JazNs 320 | 321 | ### May 20, 2021 322 | 323 | **Meeting is cancelled.** 324 | 325 | ### May 6, 2021 326 | 327 | #### Participants 328 | * Fatih Degirmenci (Ericsson Software Technology) 329 | * Steve Taylor (DeployHub/Ortelius) 330 | * Mattias Linnér (Ericsson) 331 | * Oliver Nocon (SAP) 332 | * Kara de la Marck (CloudBees) 333 | * Ramin Akhbari (eBay) 334 | * Jeremy Stanley (OpenDev/Zuul) 335 | * Emil Bäckmark (Ericsson) [just first few minutes] 336 | 337 | #### Agenda and Notes 338 | * Action Item Review, All 339 | * Standardized Metadata, All 340 | * https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ 341 | * IEEE Standard for DevOps, All 342 | * [Standard is available for purchase](https://standards.ieee.org/standard/2675-2021.html) 343 | * Policy Driven CI/CD, All 344 | * Discussion on the [latest contributions](https://hackmd.io/__6IAnVuR8C8mPD--XMbWg?view) 345 | * CDF End User Council Plan is available here: https://github.com/cdfoundation/end-user-council/blob/main/End%20User%20Council%20Plan%202021.pdf 346 | 347 | #### Action Items 348 | * Fatih and Steve to start a discussion around selected area(s)/topic(s) as GitHub discussions 349 | * Candidate is File Information from SPDX Specification: https://spdx.github.io/spdx-spec/4-file-information/ 350 | * Fatih to enable GitHub discussions for sig-interoperability repository 351 | * Done: https://github.com/cdfoundation/sig-interoperability/discussions 352 | * Kara to help out reaching out to OPA community 353 | 354 | #### Meeting Recording 355 | * https://www.youtube.com/watch?v=fNRiLtQFhkI 356 | 357 | ### April 15, 2021 358 | 359 | #### Participants 360 | * Ramin Akhbari (eBay) 361 | * Fatih Degirmenci (Ericsson Software Technology) 362 | * Kara de la Marck (CloudBees) 363 | * Mattias Linnér (Ericsson) 364 | * Kate Stewart (LF) 365 | * Emil Bäckmark (Ericsson) 366 | * Andrea Frittoli (IBM) 367 | * Alois Reitbauer (Dynatrace) 368 | * Gale McCommons (LF) 369 | * Tracy Miranda (CDF) 370 | * Gopinath Rebala (OpsMX) 371 | * Tracy Ragan (DeployHub/Ortelius) 372 | * Ola (Telus) 373 | * Victor Martinez (Elastic) 374 | * Steve Taylor (DeployHub/Ortelius) 375 | 376 | #### Agenda and Notes 377 | * Action Item Review, All 378 | * Next SIG Interoperability Meeting, All 379 | * Next meeting is on May 6, 2021. 380 | * KubeCon CloudNativeCon Europe 2021 takes place between May 4-7, 2021. 381 | * We will meet as usual and see how many joins 382 | * cdCon Schedule Announcement, All 383 | * [cdCon Schedule](https://events.linuxfoundation.org/cdcon/program/schedule/) 384 | * [GitOps Summit Schedule](https://events.linuxfoundation.org/gitops-summit/program/schedule/) 385 | * [Spinnaker Summit Schedule](https://events.linuxfoundation.org/spinnaker-summit/program/schedule/) 386 | * [Registration Link](https://events.linuxfoundation.org/cdcon/register/) 387 | * SPDX Presentation and Discussion, Kate Stewart, All 388 | * SBOM (Software Bill of Materials) -- formal record of details and supply chain relationships of the components used in building software. Anything running on a system you should be able to represent and be able to query that representation. 389 | * https://spdx.github.io/spdx-spec/7-relationships-between-SPDX-elements/ 390 | * https://github.com/spdx/spdx-spec/issues 391 | * https://docs.google.com/presentation/d/1YNtXPRGuj9hri_rGid_E7LZ9OODcNASbdNmNOOOzFAk/edit#slide=id.gd25d926f37_0_155 392 | * Policy Driven CI/CD, All 393 | * Discussion on the [latest contributions](https://hackmd.io/__6IAnVuR8C8mPD--XMbWg?view) 394 | 395 | #### Action Items 396 | * ~~Emil B to add notes on mandatory, optional data and digest to artifact metadata document. *Done, comments added to the metadata document.*~~ 397 | 398 | #### Meeting Recording 399 | * https://www.youtube.com/watch?v=pW7_x9nWC7s 400 | 401 | ### April 1, 2021 402 | 403 | #### Participants 404 | * Kara de la Marck (CloudBees) 405 | * Ramin Akhbari (eBay) 406 | * Fatih Degirmenci (Ericsson Software Technology) 407 | * Steve Taylor (DeployHub/Ortelius) 408 | * Oliver Nocon (SAP) 409 | * Tracy Miranda (CDF) 410 | * Andrea Frittoli (IBM) 411 | * Emil Bäckmark (Ericsson) 412 | * Vincent Behar (Dailymotion) 413 | * Tracy Ragan (DeployHub/Ortelius) 414 | 415 | #### Agenda and Notes 416 | * Action Item Review, All 417 | * Standardized Metadata, All 418 | * Discussion on [Artifact Metadata](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ?view#Artifacts) contributed by Steve T 419 | * ST: Summarizes the contribution he made for artifact metadata 420 | * Collaboration with [SPDX](https://github.com/spdx) 421 | * FD: [Announcement of SPDX Submission to ISO](https://www.linuxfoundation.org/blog/spdx-specification-becomes-the-second-iso-iec-jtc-1-submission-from-jdf/) 422 | * FD: [Draft Spec Preview](https://www.iso.org/obp/ui/#iso:std:iso-iec:5962:dis:ed-1:v1:en) 423 | * FD: [SPDX Topic in LF Spring Member Meeting](https://www.youtube.com/watch?v=DrRJXi5aGuI&t=780s) 424 | * ST: Shares his thoughts on SPDX Version 1.2. Version 2 is little bit harder. 425 | * TM: SPDX community is working on Version 3. Related work such as SBOM is rolling under SPDX. 426 | * TM: We could bring the perspective from CI/CD domain. 427 | * FD: Kate Stewart from SPDX will join to SIG Interoperability Meeting on April 15th. 428 | * DORA and SPACE metrics with Jenkins X, Vincent Behar 429 | * [More on Nicole Forsgren's SPACE metrics](https://queue.acm.org/detail.cfm?id=3454124) 430 | * See [Vincent's recent presentation at Jenkins X Office Hours](https://www.youtube.com/watch?v=ncxVtltXgno) 431 | * [Jenkins X doc for CD Indicators](https://jenkins-x.io/v3/admin/guides/observability/cd-indicators/) 432 | * [Jenkins X CD Indicators Collector (github repo)](https://github.com/jenkins-x/cd-indicators) 433 | * Policy Driven CI/CD, All 434 | * Postponed to one of the upcoming meetings. 435 | * Discussion on the [latest contributions](https://hackmd.io/__6IAnVuR8C8mPD--XMbWg?view) 436 | 437 | #### Action Items 438 | * ~~Steve T to start the work on artifact metadata and bring example from Ortelius~~ 439 | * ~~Fatih D and Tracy M to update SIG Interopereability meeting time to 15:00UTC.~~ 440 | * Emil B to add notes on mandatory, optional data and digest to artifact metadata document. *Done, comments added to the metadata document.* 441 | 442 | #### Meeting Recording 443 | * https://www.youtube.com/watch?v=-YPPa-wrTo8 444 | 445 | ### March 18, 2021 446 | 447 | #### Participants 448 | * Kara de la Marck (CloudBees) 449 | * Fatih Degirmenci (Ericsson Software Technology) 450 | * Oliver Nocon (SAP) 451 | * Mattias Linnér (Ericsson) 452 | * Emil Bäckmark (Ericsson) 453 | * Jeremy Stanley (OpenDev/Zuul) 454 | * Tracy Miranda (CDF) 455 | * Terry Cox (Bootstrap) 456 | * Andrea Frittoli (IBM) 457 | * Ramin Akhbari (eBay) 458 | * Andreas Grimmer (Dynatrace) 459 | * Dina Graves Portman (Google) 460 | * Gareth Evans (CloudBees) 461 | 462 | #### Agenda and Notes 463 | * Action Item Review, All 464 | * Daylight Saving Time Changes Check, All 465 | * US@March 14th, Europe@March 28th 466 | * Meeting time on April 1st? 467 | * https://time.is/1600_1_April_2021_in_UTC 468 | * SIG Interoperability switches to 15:00UTC for summer. 469 | * [PR to add CD definitions](https://github.com/cdfoundation/glossary/pull/10) (from Christie who can't make it, just wanted to make sure ppl know about it!) 470 | * End User Forum Discussion on Measuring DevOps Success, Tracy Miranda 471 | * There will be a discussion/panel on this topic on 31 March 472 | * [link to Register](https://www.crowdcast.io/e/356fkadm/register) 473 | * Four Keys Project, Dina Portman 474 | * Presentation on [Four Keys](https://github.com/GoogleCloudPlatform/fourkeys) 475 | * Follow up discussion on potential collaboration opportunities 476 | * Policy Driven CI/CD, All 477 | * Discussion on the latest contributions if time permits 478 | * https://hackmd.io/__6IAnVuR8C8mPD--XMbWg?view 479 | 480 | #### Action Items 481 | * Steve T to start the work on artifact metadata and bring example from Ortelius 482 | * ~~Fatih D to send mail to CDF SIG/TOC/End User maillists for Dina Portman's visit to SIG Interoperability on March 18th~~ 483 | * ~~Kara M to help with Jenkins and CloudBees policy approach~~ 484 | * ~~Fatih D to reach out to Cameron for Armory policy approach~~ 485 | * ~~Oliver N to upload Project "Piper" presentation to [CDF Presentations repository](https://github.com/cdfoundation/presentations)~~ 486 | * Fatih D and Tracy M to update SIG Interopereability meeting time to 15:00UTC. 487 | 488 | #### Meeting Recording 489 | * https://www.youtube.com/watch?v=H3Lc2URIKXo 490 | 491 | ### March 4, 2021 492 | 493 | #### Participants 494 | * Kara de la Marck (CloudBees) 495 | * Ramin Akhbari (eBay) 496 | * Mattias Linnér (Ericsson) 497 | * Fatih Degirmenci (Ericsson Software Technology) 498 | * Emil Bäckmark (Ericsson) 499 | * Steve Taylor (DeployHub) 500 | * Oliver Nocon (SAP) 501 | * Andrea Frittoli (IBM) 502 | * Jeremy Stanley (OpenDev/Zuul) 503 | * Andreas Grimmer (Dynatrace) 504 | * Tracy Ragan (DeployHub) 505 | 506 | #### Agenda and Notes 507 | * Action Item Review, All 508 | * Daylight Saving Time Changes, All 509 | * US@March 14th, Europe@March 28th 510 | * The meeting on March 18th falls in between... 511 | * 16:00UTC - 9am for PT, 10am MT, 12noon ET, 4pm BST/CET 512 | * https://time.is/1600_18_March_2021_in_UTC 513 | * cdCon, All 514 | * CFP is open, March 5th is the deadline for final deadline 515 | * Tomorrow is the deadline! 516 | * https://events.linuxfoundation.org/cdcon/program/cfp/ 517 | * Heads up on upcoming discussion with Dina Portman, Tracy Miranda 518 | * Dina will join our meeting on March 18th 519 | * The project Dina is working on [Four Keys](https://github.com/GoogleCloudPlatform/fourkeys) 520 | * Please do invite additional attendees who may be interested in this work -- from other SIG groups, etc 521 | * Policy Driven CI/CD, All 522 | * Discussion on the latest contributions 523 | * https://hackmd.io/__6IAnVuR8C8mPD--XMbWg?view 524 | * Standardized Metadata, James Strachan, Dave Sudia, Steve Taylor 525 | * [Repository](https://github.com/cdfoundation/standardized-metadata) 526 | * [HackMD file](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ) 527 | * Note: Share and discuss with Dina Portman, as her feedback would be beneficial. 528 | * [Project "Piper"](https://www.project-piper.io/) Presentation, Oliver Nocon 529 | * JobDSL blog post: https://jenkins-x.io/v3/admin/guides/jenkins/getting-started/#job-dsl 530 | * An abrupt end to the meeting! :-) 531 | * However, we will continue discussing using events to enable greater flexibility and composability between pipelines at the next meeting. 532 | 533 | 534 | #### Action Items 535 | * Steve T to start the work on artifact metadata and bring example from Ortelius 536 | * Fatih D to send mail to CDF SIG/TOC/End User maillists for Dina Portman's visit to SIG Interoperability on March 18th 537 | * Kara M to help with Jenkins and CloudBees policy approach 538 | * Fatih D to reach out to Cameron for Armory policy approach 539 | * Oliver N to upload Project "Piper" presentation to [CDF Presentations repository](https://github.com/cdfoundation/presentations) 540 | * ~~Tracy M to get SIG Interop in touch with Dina Graves Portman and invite her to one of the upcoming SIG meetings~~ 541 | * ~~Fatih D to create a new document to start the work on Policy Driven CI/CD and send an email~~ 542 | * ~~Tracy R to include policy related information from Ortelius and DeployHub Pro on the policy document as examples~~ 543 | * ~~Andrea F to include policy related information from Tekton on the policy document as an example~~ 544 | * ~~Events & Interop SIGs to provide quotes for CDF announcement of SIG Events - deadline March 1st, Emil, Andrea, Kara, Fatih~~ 545 | * ~~Fatih D to add user/project input to policy document based on the discussion from the meeting~~ 546 | * ~~Fatih D to add Project Piper to the agenda of upcoming SIG meeting~~ 547 | 548 | #### Meeting Recording 549 | * https://www.youtube.com/watch?v=LbdMG0O4m6Y 550 | 551 | ### February 18, 2021 552 | 553 | #### Participants 554 | * Ramin Akhbari (eBay) 555 | * Emil Bäckmark (Ericsson) 556 | * Fatih Degirmenci (Ericsson Software Technology) 557 | * Mattias Linnér (Ericsson) 558 | * Oliver Nocon (SAP) 559 | * Christie Wilson (half!) (Google) 560 | * Tracy Ragan (DeployHub) 561 | * Vibhav Bobade (RedHat) 562 | * Jeremy Stanley (OpenDev/Zuul) 563 | * Andrea Frittoli (IBM) 564 | * Tracy Miranda (CDF) 565 | 566 | #### Agenda and Notes 567 | * Action Item Review, All 568 | * Events SIG, All 569 | * It is official!: https://lists.cd.foundation/g/cdf-toc/message/614 570 | * Recording of the discussion on events during CDF Meetup: https://lists.cd.foundation/g/cdf-toc/message/614 571 | * Policy Driven CI/CD, All 572 | * The document to collect information is available on [HackMD.io](https://hackmd.io/__6IAnVuR8C8mPD--XMbWg) 573 | * Standardized Metadata, James Strachan, Dave Sudia, Steve Taylor 574 | * [Repository](https://github.com/cdfoundation/standardized-metadata) 575 | * [HackMD file](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ) 576 | * Interopability Whitepaper, All 577 | * cdCon, All 578 | * CFP is open, March 5th is the deadline for final deadline 579 | * Early bird deadline is February 19 580 | 581 | #### Action Items 582 | * Dave to start the work on artifact metadata, Steve volunteered to help 583 | * Steve/Tracy R to bring Ortelius standardized metadata example in new repo 584 | * Tracy M to get SIG Interop in touch with Dina Graves Portman and invite her to one of the upcoming SIG meetings 585 | * Fatih D to create a new document to start the work on Policy Driven CI/CD and send an email 586 | * Tracy R to include policy related information from Ortelius and DeployHub Pro on the policy document as examples 587 | * Andrea F to include policy related information from Tekton on the policy document as an example 588 | * Events & Interop SIGs to provide quotes for CDF announcement of SIG Events - deadline March 1st, Emil, Andrea, Kara, Fatih 589 | * ~~Fatih D to contact Tracy R for possible Policy Driven CI/CD presentation to CDF Meetup~~ 590 | * Fatih D to add user/project input to policy document based on the discussion from the meeting 591 | * Fatih D to add Project Piper to the agenda of upcoming SIG meeting 592 | 593 | #### Meeting Recording 594 | * https://www.youtube.com/watch?v=7fVPnBVTMYA 595 | 596 | ### February 4, 2021 597 | 598 | #### Participants 599 | * Oliver Nocon (SAP) 600 | * Fatih Degirmenci (Ericsson Software Technology) 601 | * Emil Bäckmark (Ericsson) 602 | * Mattias Linnér (Ericsson) 603 | * Steve Taylor (DeployHub) 604 | * Vibhav Bobade (Red Hat) 605 | * Andrea Frittoli (IBM) 606 | * Gareth Evans (CloudBees) 607 | * Anthony O'Gorman (Fidelity Investments) 608 | * Tracy Ragan, DeployHub / Ortelius 609 | * Dave Sudia (UPchieve) 610 | * Jeremy Stanley (OpenDev/Zuul) 611 | 612 | #### Agenda and Notes 613 | * Action Item Review, All 614 | * FOSDEM 2021, Kara de la Marck, Fatih Degirmenci 615 | * CI/CD Devroom on Sunday, February 7! 616 | * Fellow community members [presenting](https://fosdem.org/2021/schedule/track/continuous_integration_and_continuous_deployment/) CDF/SIG 617 | * Policy Driven CI/CD, Fatih Degirmenci 618 | * [Slides](https://docs.google.com/presentation/d/1MHBpzxDqGAp2NYcyNHvCPVOVu2JF_-cVXemvPKWz-JU/edit?usp=sharing) 619 | * The topic gathered interest. 620 | * A new document will be created to collect existing approaches to policy to work on this further. 621 | * It is proposed to bring this topic to the SIG Best Practices and End User Council. 622 | * Standardized Metadata, James Strachan, Dave Sudia, Steve Taylor 623 | * [Repository](https://github.com/cdfoundation/standardized-metadata) 624 | * Steve Taylor summarized the updates he made about Git commit SHA on [HackMD document](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ?view#Git-Commit-SHA) 625 | * Ortelius Presentation/Demo, Steve Taylor 626 | * Presentation given. The meeting recording should be available on Youtube soon. 627 | 628 | #### Action Items 629 | * ~~Ramin A to bring an example manifest from eBay for metadata topic - Fatih to remind~~ 630 | * ~~Tracy R/Steve T to demo Ortelius (manifest/metadata/visibility focused), 21st January~~ 631 | * ~~Events in CI/CD workstream to provide input to standardized metadata topic based on their discussions~~ 632 | * The group will come back when there is progress with commit and artifact metadata 633 | * ~~Tracy M to bring the whitepaper to the attention of CDF creative team~~ 634 | * ~~Steve to start the work on commit metadata~~ 635 | * Dave to start the work on artifact metadata, Steve volunteered to help 636 | * Steve/Tracy R to bring Ortelius example in new repo 637 | * Tracy M to get SIG Interop in touch with Dina Graves Portman and invite her to one of the upcoming SIG meetings 638 | * ~~Kara and Fatih to populate references in whitepaper~~ 639 | * Fatih D to create a new document to start the work on Policy Driven CI/CD 640 | * Tracy R to include policy related information from Ortelius and DeployHub Pro on the policy document as examples 641 | * Andrea F to include policy related information from Tekton on the policy document as an example 642 | * Fatih D to contact Tracy R for possible Policy Driven CI/CD presentation to CDF Meetup 643 | 644 | #### Meeting Recording 645 | * https://www.youtube.com/watch?v=VqoZy4E-ijo 646 | 647 | ### January 21, 2021 648 | 649 | #### Participants 650 | * Fatih Degirmenci, Ericsson Software Technology 651 | * Andreas Grimmer, Dynatrace 652 | * Mattias Linnér, Ericsson 653 | * Kara de la Marck, CloudBees 654 | * Christie Wilson, Google 655 | * Tracy Miranda, CDF 656 | * Emil Bäckmark, Ericsson 657 | * Anthony O'Gorman, Fidelity Investments 658 | * Oliver Nocon (SAP) 659 | * Jeremy Stanley, OpenDev/Zuul 660 | * Andrea Frittoli, IBM 661 | 662 | #### Agenda and Notes 663 | * Action Item Review, All 664 | * Events in CI/CD becoming SIG, Workstream Members 665 | * EB: Draft charter for the SIG was presented to CDF TOC on January 19. Positive response received. 666 | * AG: Charter had priority and contribution to standardized metadata is in the backlog. 667 | * Interoperability Whitepaper, Tracy Miranda 668 | * TM: Work is in progress by the creative team. References is empty and will be . 669 | * TM: Content will be massaged and visuals will be included. 670 | * TM: Additional feedback will be asked to the community members. 671 | * cdCon Update, Tracy Miranda 672 | * TM: CFP is open. 673 | * TM: Early bird submissions are open and 5 proposal will be selected and highlighted as Early Bird picks by the programming committee. 674 | * TM: Proposals are welcome. 675 | * TM: Hopin platform is integrated with the tool [Miro](https://miro.com) to collaboratively/interactively work on visual material. 676 | * End User Council Update, Tracy Miranda 677 | * TM: End User Council has its [own repo](https://github.com/cdfoundation/end-user-council). 678 | * TM: End User Council published 2021 plan and the material is available in [End User Repo on GitHub](https://github.com/cdfoundation/end-user-council/blob/main/End%20User%20Council%20Plan%202021.pdf). 679 | * TM: There will be discussions relevant to Interoperability area and there will be discussions on the topic in End User Council. 680 | * SIG Interoperability One Year Old, All 681 | * [Blog post](https://cd.foundation/blog/2021/01/19/cdf-sig-interoperability-2020-year-in-review/) celebrating this 682 | * [Continuous Delivery Definitions](https://docs.google.com/document/d/1IUSmgtw5eC2JwyfiX7IPK3twl3MSjWAsmCKmJ6Y5z-w/edit#), [CD timeline](https://github.com/cdfoundation/glossary/blob/main/timeline.md), Christie Wilson 683 | * CW: The discussion on definitions started in this group so I wanted to give an update to the group. 684 | * CW: The interoperability whitepaper had a section to describe CI and CD and there were lots of conversations on the topic. 685 | * CW: One thing I did was to get some progress was to create a timeline to see when/where these things were originated. Both Continues Deliver and Continuous Deployment appeared same year. 686 | * CW: First appearance of Continuous Delivery was in [Agile Manifesto](https://agilemanifesto.org/principles.html) 687 | * FD: What about related terms such as DevOps, DevSecOps, GitOps, Progressive Delivery? (https://github.com/cdfoundation/glossary/issues/7) 688 | * TM: Can help out with them. 689 | * CW: Jez Humble tries to explain the differences between and reasons for (e.g., business) Continuous Delivery vs Continuous Deployment. (https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/) 690 | * KM & CW: This topic could feed into the work done in CDF Best Practices SIG. 691 | * TM: Everybody has a different view on Continuous Delivery and Continuous Deployment. If we say Continuous Delivery is much wider and what other things it compasses. 692 | * TM: What are the best practices for using SCM, deployment strategy, trunk based development, GitOps, advanced bots, ChatOps. 693 | * TM: Best Practices SIG started the work recently. 694 | * AO: [SIG Best Practices](https://github.com/cdfoundation/sig-best-practices) is a good idea an want to be involved in it. 695 | * Ortelius Presentation/Demo, Tracy Ragan, Steve Taylor 696 | * Postponed 697 | 698 | #### Action Items 699 | * Ramin A to bring an example manifest from eBay for metadata topic - Fatih to remind 700 | * Tracy R/Steve T to demo Ortelius (manifest/metadata/visibility focused), 21st January 701 | * Events in CI/CD workstream to provide input to standardized metadata topic based on their discussions 702 | * Tracy M to bring the whitepaper to the attention of CDF creative team 703 | * ~~Tracy M to help with creation of a repo for standardized-metadata, https://github.com/cdfoundation/foundation/issues/262~~ 704 | * Repo is ready: https://github.com/cdfoundation/standardized-metadata 705 | * Steve to start the work on commit metadata 706 | * Dave to start the work on artifact metadata 707 | * ~~Emil to bring Eiffel example in new repo - https://github.com/cdfoundation/standardized-metadata/pull/3~~ 708 | * Steve/Tracy R to bring Ortelius example in new repo 709 | * Tracy M to get SIG Interop in touch with Dina Graves Portman and invite her to one of the upcoming SIG meetings 710 | * Kara and Fatih to populate references in whitepaper 711 | * \ 712 | 713 | #### Meeting Recording 714 | * \ 715 | 716 | ### January 7, 2021 717 | 718 | #### Participants 719 | * Fatih Degirmenci, Ericsson Software Technology 720 | * Andrea Frittoli, IBM 721 | * Oliver Nocon, SAP 722 | * Kara de la Marck, CloudBees 723 | * Dave Sudia, UPchieve 724 | * Jeremy Stanley, OpenDev/Zuul 725 | * James Strachan, CloudBees 726 | 727 | #### Agenda and Notes 728 | * Action Item Review, All 729 | * Archival of 2020 Meeting Minutes, All 730 | * The minutes of past meetings available [here](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2020.md) 731 | * Upcoming Events, All 732 | * [FOSDEM 2021](https://fosdem.org/2021/), 6-7 February 2021 733 | * [CI/CD Devroom schedule](https://fosdem.org/2021/schedule/track/continuous_integration_and_continuous_deployment/) published 734 | * CI/CD Devroom happens on February 7 735 | * 2 talks from SIG are accepted 736 | * [The Road to Interoperability in CI/CD](https://fosdem.org/2021/schedule/event/the_road_to_interoperability_in_ci_cd/) by Fatih Degirmenci and Kara de la Marck 737 | * [Events in CI/CD](https://fosdem.org/2021/schedule/event/events_in_ci_cd/) by Andrea Frittoli 738 | * [cdCon 2021](https://events.linuxfoundation.org/cdcon/), 23-24 June 2021 739 | * TM: CFP opens Monday, January 11th. CFP may stay open until after FOSDEM. 740 | * TM: SIG Interoperability will be reached out for Birds of Feather session. 741 | * TM: Registration is already open: https://events.linuxfoundation.org/cdcon/register/ 742 | * TM: Expectation is to have about 3000 people. (300 already registered.) 743 | * Events in CI/CD Workstream to become a separate SIG, Workstream Members 744 | * AF: The work on charter started happening and the discussion will happen during the very first meeting of the Events in CI/CD Workstream. 745 | * AF: The Events in CI/CD workstream meeting will happen on January 18th, 16:00UTC. 746 | * AF: The working document is here - still WIP: https://docs.google.com/document/d/1cuaOHmrvK20WxHxHZZuLif3CW3q1ICZ_RglJRp_IAQ0/edit?usp=sharing 747 | * FD: The topic of Events in CI/CD workstream becoming top level SIG will be discussed during the next CDF TOC Meeting on January 19th. 748 | * FD: CDF TOC Meeting logistics/agenda/minutes available here: https://docs.google.com/document/d/1uBHar55fTInWF9Li4t0lyG3tTC8BRLU0FfBfsgk_Jrs/edit?ts=5c9580be#heading=h.en8cy6hno0c6 749 | * KM: What kind of collaboration is happening toward CloudEvents? 750 | * AF: Not much happening with CloudEvents yet but we were thinking of using CloudEvents for transport. Need to check. 751 | * [Standardized Metadata](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ), James Strachan, All 752 | * DS: Where should the repo be? 753 | * FD: The repo will be in CDF organisation. 754 | * DS: Reached out to CNCF GitOps WG and SIG App Delivery and few people shown interest. Already got contribution for ArgoCD to Rosetta Stone CI/CD document. 755 | * CDF End User Community, Tracy Miranda 756 | * TM: Very first topic everyone unanomously agreed was measuring DevOps Success. (e.g. MTTR from DORA folks) 757 | * TM: Link to blog post on measuring Devops: https://cd.foundation/blog/2020/11/05/measuring-devops/ 758 | * TM: There will be discussions on what everyone is doing, how they are measuring. 759 | * TM: The group is keen on connecting what CDF is doing and the projects and groups under CDF. 760 | * TM: cdCon 2020 Tekton talk on how to collect metrics and display them on dashboard. 761 | * TM: This topic could be considered as a focus area within SIG Interoperability and we can schedule a call with the group and Dina Graves Portman. 762 | * TM: A demo could be made to this group. 763 | * TM: There are already open source/propietary tools/dashboards such as Spinnaker, CloudBees so it would be good to get input from them as well. 764 | 765 | #### Action Items 766 | * ~~Fatih to ping Cameron on Jenkins Spinnaker for whitepaper~~ 767 | * Ramin A to bring an example manifest from eBay for metadata topic 768 | * Tracy R/Steve T to demo Ortelius (manifest/metadata/visibility focused), 21st January 769 | * Events in CI/CD workstream to provide input to standardized metadata topic based on their discussions 770 | * Tracy M to bring the whitepaper to the attention of CDF creative team 771 | * ~~Tracy M to help with updating meeting invitation according to what is agreed~~ 772 | * Tracy M to help with creation of a repo for standardized-metadata, https://github.com/cdfoundation/foundation/issues/262 773 | * Steve to start the work on commit metadata 774 | * Dave to start the work on artifact metadata 775 | * Emil to bring Eiffel example in new repo 776 | * Steve/Tracy R to bring Ortelius example in new repo 777 | * Tracy to get SIG Interop in touch with Dina Graves Portman and invite her to one of the upcoming SIG meetings 778 | 779 | #### Meeting Recording 780 | * https://www.youtube.com/watch?v=655DDU3_AY8 781 | -------------------------------------------------------------------------------- /docs/meetings_2022.md: -------------------------------------------------------------------------------- 1 | ###### tags: `CDF` `SIG Interoperability` 2 | 3 | # CDF Interoperability SIG Meetings 2022 4 | 5 | [![HacmKD documents](https://hackmd.io/badge.svg)](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A?edit) 6 | 7 | ## Note 8 | 9 | This document contains the minutes of the SIG Interoperability meetings held during 2022 and kept for historical/archive purposes. 10 | Please do not edit this document. 11 | 12 | If you are looking for the latest SIG Interoperability minutes of meetings, please head over to [CDF Interoperability SIG Meetings document](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A?view). 13 | 14 | ## Quick links 15 | 16 | * [Logistics](#Logistics) 17 | * [Meeting Recordings](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 18 | * [Agenda and Notes](#Agenda-and-Notes) 19 | 20 | * 2022-12-15/2023-01-05 Meetings Cancelled for Winter Break 21 | * [2022-12-01 Meeting](#December-1-2022) 22 | * [2022-11-17 Meeting](#November-17-2022) 23 | * 2022-11-03 Meeting (Cancelled) 24 | * [2022-10-20 Meeting](#October-20-2022) 25 | * [2022-10-06 Meeting](#October-6-2022) 26 | * [2022-09-15 Meeting](#September-15-2022) 27 | * [2022-09-01 Meeting](#September-1-2022) 28 | * [2022-08-18 Meeting](#August-18-2022) 29 | * [2022-08-04 Meeting](#August-4-2022) 30 | * [2022-07-21 Meeting](#July-21-2022) 31 | * [2022-07-07 Meeting](#July-7-2022) 32 | * [2022-06-16 Meeting](#June-16-2022) 33 | * [2022-06-02 Meeting](#June-2-2022) 34 | * 2022-05-19 Meeting (Cancelled) 35 | * 2022-05-05 Meeting (Cancelled) 36 | * [2022-04-21 Meeting](#April-21-2022) 37 | * [2022-04-07 Meeting](#April-7-2022) 38 | * [2022-03-17 Meeting](#March-17-2022) 39 | * [2022-03-03 Meeting](#March-3-2022) 40 | * [2022-02-17 Meeting](#February-17-2022) 41 | * [2022-02-03 Meeting](#February-3-2022) 42 | * [2022-01-20 Meeting](#January-20-2022) 43 | 44 | ## Logistics 45 | 46 | * **Meeting notes on HackMD.io**: https://hackmd.io/@cdfoundation/ry3TTB5DL 47 | * **When**: First and third Thursdays at [3pm UTC](https://time.is/3pm_in_UTC) during summer time and at [4pm UTC](https://time.is/4pm_in_UTC) during winter time). 48 | * **Zoom Bridge**: https://zoom.us/j/827082528?pwd=RlN5OUZtVVBuZGZRY0NBRnZyZ0NJQT09 49 | * **Zoom International dial-in numbers**: https://zoom.us/zoomconference 50 | * **Meeting Recordings**: [CDF Youtube Channel SIG Interoperability Playlist](https://www.youtube.com/playlist?list=PL2KXbZ9-EY9QxICOnONBFPn_cYfJ8BsaG) 51 | * **CDF Public Calendar**: [here](https://calendar.google.com/calendar/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24%40group.calendar.google.com&ctz=America%2FLos_Angeles) 52 | * **Past Presentations in CDF Presentations Repository**: https://github.com/cdfoundation/presentations/tree/master/sig-interoperability 53 | * **Presentation Schedule**: https://docs.google.com/document/d/1Owg_I52WEXzqF8g_lX6OTdwbHkH4Z2-7TBA7eCSVMqY/edit 54 | * **2021 Meeting Minutes**: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2021.md 55 | * **2020 Meeting Minutes**: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings_2020.md 56 | 57 | ### December 1, 2022 58 | 59 | #### Participants 60 | * Melissa McKay, JFrog 61 | * Justin Abrahms, eBay 62 | * Fatih Degirmenci, CDF 63 | 64 | #### Agenda & Notes 65 | * CDF Interoperability Whitepaper Update, All 66 | * Whitepaper will be further discussed during the meeting on January 19th. 67 | * Between now and the meeting, we will continue looking at it async to see what updates are needed. 68 | * go-scm Discussion 69 | * Will be presented at TOC meeting next week - Tues, Dec 6, 4pm UTC 70 | * History: project was forked under JenkinsX 71 | * Additional Topics 72 | * The [whitepaper](https://docs.google.com/document/d/1o5jHbuEQuspwYOruVB4L5-rG8E1wQm5chq8QN7BrrBs/edit#), [the original SIG proposal](https://github.com/cdfoundation/toc/pull/62), and previous conversations such as intent based pipelines, abstractions and so on could be discussed further. 73 | * There is also an opportunity to collaborate with [Value Stream Mapping (VSM) Interoperability Technical Committee](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vsmi) 74 | * Action Items: 75 | * Melissa - fix meeting time on CDF Public calendar, cancel next two meetings, and communicate via slack & email list that next meeting will be Jan 19th 76 | * Melissa - update past presentation SIG documentation: https://docs.google.com/document/d/1Owg_I52WEXzqF8g_lX6OTdwbHkH4Z2-7TBA7eCSVMqY/edit#heading=h.lx7kiadw52fq 77 | * Justin, Fatih, Melissa - review whitepaper 78 | * Justin, Fatih, Melissa - populate new agenda items/topics for meeting discussions (see above) 79 | 80 | ### November 17, 2022 81 | 82 | #### Participants 83 | * Justin Abrahms, eBay 84 | * Emil Bäckmark, Ericsson 85 | * Fatih Degirmenci, CDF 86 | * Terry Cox 87 | 88 | #### Agenda & Notes 89 | * CDF Interoperability Whitepaper, All 90 | * It would be good to refresh and simplify the whitepaper so it can be published. 91 | * The target date for publishing it could be 2023Q1 so we start the year with highlighting our efforts in the area. 92 | * v1: https://docs.google.com/document/d/1Bgr6EHhW4wUTphU8xyMg87qzSee43PEA_gGdMnPHq9Q/edit# 93 | * Feedback when it was originally prepping for release was "this isn't a whitepaper" 94 | * v2: https://docs.google.com/document/d/1o5jHbuEQuspwYOruVB4L5-rG8E1wQm5chq8QN7BrrBs/edit# 95 | * Removed case studies (dated, lack of point-of-contact) 96 | * Still a need for this paper to discuss the problem space 97 | * Some portions are partially addressed, but there are new emerging interoperability ideas/concerns 98 | * AI: Justin (with Melissa?) will push forward this document with a target of Q1 of 2023. 99 | * AI: Fatih to pre-flight the whitepaper idea w/ LF 100 | 101 | ### October 20, 2022 102 | 103 | #### Participants 104 | * Justin Abrahms, eBay 105 | * Fatih Degirmenci, CDF 106 | * Fog Dong, KubeVela/Alibaba Cloud 107 | * Da Ying, KubeVela/Alibaba Cloud 108 | * Qingguo Zeng 109 | * Qiao Zhongpei 110 | * Sun Jianbo 111 | * Richard Kilmurray 112 | * Terry Cox 113 | * Vedran Zdesic 114 | 115 | #### Agenda & Notes 116 | * Presentation & Open Discussion [KubeVela](https://kubevela.io/) with Da Yin & Fog Dong 117 | 118 | ### October 6, 2022 119 | 120 | #### Participants 121 | * Oliver Nocon, SAP 122 | * \ 123 | 124 | #### Agenda & Notes 125 | * Open Action Items, All 126 | * News/Announcements 127 | * Oct 20th: [KubeVela](https://kubevela.io/) 128 | * New Action Items 129 | * Presentation & Open Discussion: [FRSCA](https://buildsec.github.io/frsca/) with Parth Patel 130 | 131 | 132 | ### September 15, 2022 133 | 134 | _This meeting was cancelled due to issues with Zoom._ 135 | 136 | 137 | ### September 1, 2022 138 | 139 | #### Participants 140 | * Melissa McKay, JFrog 141 | * Andres Almiray 142 | * Justin Abrahms 143 | * Fatih Degirmenci 144 | * Kara de la Marck 145 | * Rajat Gupta 146 | * \ 147 | 148 | #### Agenda & Notes 149 | * Open Action Items, All 150 | * News/Announcements 151 | * New Action Items 152 | * Presentation & Open Discussion: [JReleaser](https://jreleaser.org/) with Andres Almiray 153 | 154 | 155 | ### August 18, 2022 156 | 157 | #### Participants 158 | * Justin Abrahms, eBay 159 | * Andrea Frittoli, IBM 160 | * Fatih Degirmenci, CDF 161 | * Melissa McKay, JFrog 162 | * Andres Almiray 163 | * Kara de la Marck, CDF 164 | * Rajat Gupta, Jenkins X 165 | * \ 166 | 167 | #### Agenda & Notes 168 | * Open Action Items (outstanding from previous meetings) 169 | * Justin: [Intent based pipelines article](https://cd.foundation/blog/2022/07/13/help-wanted-intent-based-pipelines/) 170 | * possibly an abstraction layer between definition and implementation? 171 | * Take a look at [GitOps Toolkit - WeaveWorks](https://github.com/weaveworks/weave-gitops) 172 | * Possible follow up with tweet/etc 173 | * Melissa: Determine WHERE in the best practices site to add vocabulary documentation (https://bestpractices.cd.foundation/); Review Terry's suggestions from last meeting 174 | * Possibly Learn section or Resources? 175 | * Posting vendor specific information on the Best Practices site feels off, but perhaps linking via a References section makes sense 176 | * Fatih & Ann Marie: address vocabulary split and conflicts in outstanding PRs 177 | * Waiting for review 178 | * Melissa/Justin: scheduling a presentation time for go-scm & FRSCA 179 | * Queries have gone to both for availability 180 | * CDEvents and Pipeline terminology alignment 181 | * Other announcements 182 | * JReleaser will be presenting Sep 1 183 | * Our github default branch has been renamed from master to main - thank you Kara! 184 | * Future topics for the Interoperability SIG to consider (open discussion) 185 | * New Landscape Category 186 | * https://github.com/cdfoundation/cdf-landscape/issues/243 187 | * Moving forward with adding new category (open to later name change) 188 | * New Action Items: 189 | * Andrea: Make PR for link back to tools doc from Best Practices site 190 | * https://github.com/cdfoundation/best-practices-site/pull/26 191 | * Fatih: Give Justin a list of names of project maintainers 192 | * Justin: Reach out to project maintainers regarding Interoperability issues 193 | * Melissa: Start convo in slack channel(s) regarding new ideas for Interoperability topics 194 | 195 | ### August 4, 2022 196 | 197 | #### Participants 198 | * Melissa McKay, JFrog 199 | * Kara de la Marck, CDF 200 | * Tim Miller, Kusari 201 | 202 | #### Agenda & Notes 203 | * Reference Architecture discussions will be continued in the Best Practices SIG (possibly a new working group) 204 | * New projects to present to the SIG 205 | * go-scm - [ACTION] agree on a scheduled time for presentation 206 | * JReleaser - schedule presentation Sep 1 207 | * FRSCA Project - https://github.com/buildsec/frsca 208 | * [ACTION] - schedule a presentation 209 | * [CDF Landscape](https://github.com/cdfoundation/cdf-landscape) 210 | * We welcome PRs to add projects -- JReleaser now added 211 | * If you feel a category is missing, please raise an issue 212 | 213 | 214 | ### July 21, 2022 215 | 216 | #### Participants 217 | * Justin Abrahms, eBay 218 | * Kara de la Marck, CDF 219 | * Fatih Degirmenci, CDF 220 | * Terry Cox 221 | 222 | #### Agenda & Notes 223 | * Reference Architecture chat 224 | * [deck around what a reference architecture is](https://docs.google.com/presentation/d/1SSSHPLSXEUgg0vu644zrZPvCW9sUYSBwzSCDO_fZtF8/edit#slide=id.g13b9833d9a3_0_28) 225 | * current docs/projects are "open source & bottom up" which don't take a hollistic view of the whole problem space 226 | * There are two camps, from user interviews: 227 | * folks who are steeped in CD culture 228 | * folks who have a loose grasp on what CD means but need some help understanding how to get value from it or get from where they are to where they need to be 229 | * The work will be to define the common patterns used in pipelines 230 | * The MLOps space, as an example, is not very well connected to traditional CD pipelines. 231 | * https://github.com/cdfoundation/sig-mlops/blob/master/roadmap/2021/MLOpsRoadmap2021.md 232 | 233 | ### July 7, 2022 234 | 235 | #### Participants 236 | * Justin Abrahms, eBay 237 | * Kara de la Marck, CDF 238 | * Melissa McKay, JFrog 239 | * Andrea Frittoli, IBM 240 | * Ann Marie Fred, Red Hat 241 | * \ 242 | 243 | #### Agenda and Notes 244 | * Introduction - Justin Abrahms, new Co-Chair 245 | * Presentation - Uffizzi by Josh Thurman 246 | * on demand environments in k8s 247 | * designed to work with any ci/cd platform 248 | * triggered by cd events (maybe also CDEvents??) 249 | * QUICK LINKS- 250 | * Open Source Repo https://github.com/UffizziCloud/uffizzi_app 251 | * Public Road Map https://github.com/UffizziCloud/roadmap 252 | * GHA https://github.com/UffizziCloud/preview-action 253 | * Uffizzi https://uffizzi.com/ 254 | * Docs https://docs.uffizzi.com. https://github.com/UffizziCloud/docs 255 | * Uffizzi Users Slack https://uffizzi.slack.com/join/shared_invite/zt-ffr4o3x0-J~0yVT6qgFV~wmGm19Ux9A#/shared-invite/email 256 | * Uffizzi Helm Chart https://artifacthub.io/packages/helm/uffizzi-app/uffizzi-app 257 | * Uffizzi Newsletter Sign-up. http://eepurl.com/hsws0b 258 | * Open Action Items 259 | * Justin: intent based pipelines article 260 | * Melissa: Determine WHERE in the best practices site to add vocabulary documentation (https://bestpractices.cd.foundation/); Review Terry's suggestions from last meeting 261 | * Fatih & Ann Marie: address vocabulary split and conflicts in outstanding PRs - move to early-August meeting 262 | * CDEvents and Pipeline terminology alignment (if time permits) - move to early-August meeting 263 | 264 | ### June 16, 2022 265 | 266 | #### Participants 267 | * Melissa McKay, JFrog 268 | * Kara de la Marck, CDF 269 | * Andres Almiray 270 | * Josh Thurman 271 | * Jeremy Adams 272 | * Maria Ashby 273 | * Richard Kilmurray 274 | * Fatih Degirmenci 275 | * Andrea Frittoli 276 | * Brett Smith 277 | * \ 278 | 279 | #### Agenda and Notes 280 | * Presentation - dagger.io by Jeremy Adams 281 | * Open Discussion 282 | 283 | ### June 2, 2022 284 | 285 | #### Participants 286 | * Melissa McKay, JFrog 287 | * Kara de la Marck, CDF 288 | * Ann Marie Fred, Red Hat 289 | * Jeremy Adams, Dagger 290 | * Justin Abrahms, eBay 291 | * Emil Bäckmark, Ericsson 292 | * Fatih Degirmenci 293 | * \ 294 | 295 | #### Agenda and Notes 296 | * Action Item Review, All 297 | * Jeremy Adams, Dagger.io - June 16th scheduled presentation 298 | * SIG Interoperability Co-chair nominations/elections 299 | * NOMINATION: Justin Abrahms, eBay 300 | * Ann Marie has [a talk repping this sig](https://drive.google.com/file/d/1UoufcCfqYzcBsD2zUDaKPg9V3BBFTF4g/view?usp=sharing) next week at cdCon virtual ([sched session link](https://cdcon2022.sched.com/event/12vF9/virtual-session-continuous-integration-and-continuous-delivery-pipelines-for-beginners-and-managers-ann-marie-fred-red-hat)) and OpenInfra Summit Berlin! 301 | * [CDEventsCon wrap up blog post](https://cd.foundation/blog/2022/05/25/cdeventscon-2022-wrap-up/), including link to YouTube channel to all the talks and presentations at CDEventsCon 302 | * **ACTION ITEM:** Fatih & Ann Marie address vocabulary split and conflicts in outstanding PRs 303 | * **ACTION ITEM:** Melissa - Determine WHERE in the best practices site to add vocabulary documentation (https://bestpractices.cd.foundation/); Review Terry's suggestions from last meeting 304 | * **ACTION ITEM:** Melissa & Justin finish up article next week at cdCon 305 | 306 | 307 | ### April 21, 2022 308 | 309 | #### Participants 310 | * Fatih Degirmenci, Ericsson Software Technology 311 | * Kara de la Marck, CDF 312 | * Melissa McKay, JFrog 313 | 314 | 315 | #### Agenda and Notes 316 | * Action Item Review, All 317 | * **ACTION ITEM:** Melissa still needs to reach out to dagger.io 318 | * **ACTION ITEM:** Justin/Melissa - wrap up intent driven pipeline thoughts for article 319 | * SIG Interoperability Co-chair nominations/elections 320 | * Look for email in the mailing list and submit your nominations! 321 | * Documentation Consult with Best Practices SIG - Terry Cox & Tara Hernandez 322 | * Web site in development: [https://deploy-preview-4--preview-site-cdf-bp.netlify.app/](https://deploy-preview-4--preview-site-cdf-bp.netlify.app/) * Web site in development: [https://deploy-preview-4--preview-site-cdf-bp.netlify.app/](https://deploy-preview-4--preview-site-cdf-bp.netlify.app/) * Web site in development: [https://deploy-preview-4--preview-site-cdf-bp.netlify.app/](https://deploy-preview-4--preview-site-cdf-bp.netlify.app/) * Web site in development: [https://deploy-preview-4--preview-site-cdf-bp.netlify.app/](https://deploy-preview-4--preview-site-cdf-bp.netlify.app/) 323 | * Consider audience - our current documentation is geared toward a more technical and implementation level 324 | * Step 1: link our current reference docs as they are in resources/references section 325 | * Keep our own copy for updates and maintenance in our own repo 326 | * Update the publication on Best Practices site periodically 327 | * **ACTION ITEM:** Kara to link intial resource docs 328 | * Consider higher level audience documentation (less detail) 329 | * What is the problem you are trying to solve??? 330 | * **ACTION ITEM:** Fatih will work on higher level documentation 331 | * Discussion about maturity models 332 | * [SLSA](https://slsa.dev/) 333 | * DORA metrics 334 | * Be careful about making value judgements based on maturity/effectiveness levels 335 | * \ 336 | 337 | ### April 7, 2022 338 | 339 | #### Participants 340 | * Melissa McKay, JFrog 341 | * Fatih Degirmenci, Ericsson Software Technology 342 | * Mattias Linnér, Ericsson 343 | * Justin Abrahms, eBay 344 | * \ 345 | 346 | #### Agenda and Notes 347 | * Action Item Review, All 348 | * Open PR Reviews 349 | * [Pipeline step types proposal](https://github.com/cdfoundation/sig-interoperability/pull/81) 350 | * [Initial proposal for pipeline stage terminology](https://github.com/cdfoundation/sig-interoperability/pull/76) 351 | * ACTION ITEM: Fatih pinging all involved to resolve all items between now and next meeting, open issues where needed 352 | * Open Discussion 353 | * [What quality gates do you have?](https://github.com/cdfoundation/sig-interoperability/discussions/83) 354 | * ACTION ITEM: Justin - begin composing documentation on Quality Gates (from discussion material) 355 | * Documentation considerations 356 | * Sync with Best Practices 357 | * Consider using HackMD 358 | * Split up the documentation resulting from most recent PRs into high level vs technical implementation details 359 | * ACTION ITEM: Melissa - reach out to Best Practices SIG on documentation (invite to meeting) 360 | * New Discussion 361 | * [Slack thread (in general channel)](https://cdeliveryfdn.slack.com/archives/CJQU6EHHP/p1648923213508359) 362 | * [Intent-based pipelines](https://github.com/cdfoundation/sig-interoperability/discussions/91) 363 | * dagger.io 364 | * take a look at (for inspiration): 365 | - [shipa](https://shipa.io/miscellaneous/kubernetes-dagger-deployment-with-shipa/)? 366 | - [Crossplane & Kubernetes Workshop](https://devrel.shipa.io/cp-idp-workshop) 367 | - [Jenkins X](https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/) 368 | * ACTION ITEM: Melissa - reach out to dagger.io for a possible presentation, come up with CI yaml (ideal example) 369 | * ACTION ITEM: Justin - work on blog post about intent based pipelines (the high level concept) 370 | * \ 371 | 372 | ### March 17, 2022 373 | 374 | #### Participants 375 | * Melissa McKay, JFrog 376 | * Mattias Linnér, Ericsson 377 | * Mike Beemer, Dynatrace 378 | * Fatih Degirmenci, Ericsson Software Technology 379 | * \ 380 | 381 | #### Agenda and Notes 382 | * Action Item Review, All 383 | * Meeting time change 384 | * Meeting time change to 15:00 UTC to match up with seasonal time changes 385 | * Melissa will update on the public calendar 386 | * Presentation on the Open Feature Project by Michael Beemer 387 | * Open standard for feature flag management 388 | * https://open-feature.github.io/\ 389 | * \ 390 | 391 | ### March 3, 2022 392 | 393 | #### Participants 394 | * Kara de la Marck, CDF 395 | * Fatih Degirmenci, Ericsson Software Technology 396 | * Justin Abrahms, eBay 397 | * Mattias Linnér, Ericsson 398 | * Melissa McKay, JFrog 399 | * Ann Marie Fred, Red Hat 400 | 401 | #### Agenda and Notes 402 | * Action Item Review, All 403 | * [cdCon](https://events.linuxfoundation.org/cdcon/) Updates, CFP, Kara de la Marck 404 | * SIG Interoperability Co-chair nominations/elections 405 | * Melissa McKay has been nominated as new SIG Interoperability Chair and has accepted! Welcome Melissa McKay! 🎉 406 | * Pipeline [Steps](https://github.com/cdfoundation/sig-interoperability/pull/81)/[Stages](https://github.com/cdfoundation/sig-interoperability/pull/76)/[Quality Gates](https://github.com/cdfoundation/sig-interoperability/discussions/83) and Software Supply Chain, All 407 | * [CNCF Security TAG Software Supply Chain Best Practices](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 408 | * [Secure Software Factory RFC](https://docs.google.com/document/d/15M_Mzfqy634E_sqoslmOXsZJl4TedpbXpBjOfz-hnXk/edit#) 409 | * [SLSA](https://slsa.dev/) 410 | * [in-toto](https://in-toto.io) 411 | * Pipeline certification/badge discussion 412 | * SRE, DevOps, Quality criteria 413 | * [Operate First](https://www.operate-first.cloud/) 414 | * [Flow Framework](https://flowframework.org/) 415 | 416 | ### February 17, 2022 417 | 418 | #### Participants 419 | * Kara de la Marck, CDF 420 | * Fatih Degirmenci, Ericsson Software Technology 421 | * Anders Eknert, Styra 422 | * Jeremy Stanley, OpenDev/Zuul 423 | * Melissa McKay, JFrog 424 | * Mattias Linnér, Ericsson 425 | * Justin Abrahms, eBay 426 | * \ 427 | 428 | #### Agenda and Notes 429 | * Action Item Review, All 430 | * SIG Interoperability Co-chair nominations/elections, Fatih Degirmenci, All 431 | * [cdCon](https://events.linuxfoundation.org/cdcon/) Updates, CFP, Kara de la Marck 432 | * cdCon CFP is open until midnight 18 February -- TOMORROW!!: https://events.linuxfoundation.org/cdcon/program/cfp/#overview 433 | - Please submit a talk even if you don’t know if your company is sponsoring travel yet. 434 | - We do ask that speakers be at cdCon in person and present their talks live at cdCon. 435 | * If you think you may attend cdCon and would like to participate in a CDEvents Contributor Summit, [please fill out this form](https://docs.google.com/forms/d/e/1FAIpQLSeZGMEGldtkrj1viMcT9nQgAgHZVkIlzQZ45aTvN74992Mawg/viewform?usp=sf_link) 436 | * For each Contributor Summit, we should normally be able to provide breakfast, snacks at breaks, and beverages throughout the day. :coffee: :croissant: 437 | - So it is important for CDF to have an estimate of number of attendees 438 | * CDEvents 439 | * Repo: https://github.com/cdevents 440 | * CDEvents logo finalised: https://github.com/cdfoundation/artwork/tree/main/cdevents 441 | * CDEvents website (beta): https://cdevents.dev/ 442 | * CDEvents are on the landscape 😄 https://landscape.cd.foundation/ 443 | * And on CDF website, listed with all the other projects https://cd.foundation/projects/ 444 | * KubeCon update: CDEvents will have a full day co-located at KubeCon EU 🥳 445 | * https://github.com/cdfoundation/sig-events/issues/115 446 | * This will be officially announced soon. If you will be at [KubeCon EU](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) please do join us! 447 | * Discussion on Quality Gates: 448 | * GH Discussion: https://github.com/cdfoundation/sig-interoperability/discussions/83 449 | * Anders Eknert, from Styra, is joining us to discuss quality gates. 450 | 451 | 452 | ### February 3, 2022 453 | 454 | #### Participants 455 | * Kara de la Marck, CDF 456 | * Justin Abrahms, eBay 457 | * Oliver Nocon, SAP 458 | * fungi 459 | * \ 460 | 461 | #### Agenda and Notes 462 | * Action Item Review, All 463 | * [cdCon](https://events.linuxfoundation.org/cdcon/) Updates, CFP, Kara de la Marck 464 | * cdCon CFP is open until midnight 18 February: https://events.linuxfoundation.org/cdcon/program/cfp/#overview 465 | - Please submit a talk even if you don’t know if your company is sponsoring travel yet. 466 | - We do ask that speakers be at cdCon in person and present their talks live at cdCon. 467 | - However, restrictions are loosening around the world and travelling to cdCon will likely be possible for most individuals (although regretably maybe not for all) 468 | * We are currently organising the Contributor Summits for cdCon 2022. 469 | * The Contributor Summits are focused on CDF projects: https://cd.foundation/projects/ 470 | * For all CDF projects that are interested in hosting a Contributor Summit at cdCon, please appoint a lead organiser/host for your summit and have that individual fill out the form below: 471 | https://docs.google.com/forms/d/e/1FAIpQLSfJGFdQhFAbScBt3y3sW0WCQMl903X9T3ycmix0PpB2Zq8aoQ/viewform 472 | * The deadline to fill out the form and formally request space at cdCon is February 28. 473 | * For each Contributor Summit, we should normally be able to provide breakfast, snacks at breaks, and beverages throughout the day. :coffee: :croissant: 474 | * Fosdem is this weekend!! https://fosdem.org/2022/ 475 | * [CI/CD devroom](https://fosdem.org/2022/schedule/track/continuous_integration_and_continuous_deployment/) 476 | * SIG Interoperability Co-chair nominations/elections, Fatih Degirmenci, All 477 | * New work around terminology for pipeline [stages](https://github.com/cdfoundation/sig-interoperability/pull/76) and [steps](https://github.com/cdfoundation/sig-interoperability/pull/81) - see links to PRs. Ann Marie Fred 478 | * Updating SIG Interoperability Roadmap, Reminder 479 | * Link to the document: https://docs.google.com/document/d/1uf3sb-WJUp3Acd3WYL5SvgVECHevonufJOxd6KftOxc/edit# 480 | * Software Supply Chain 481 | * Standardized Metadata 482 | * Artifact Handling 483 | * Policy Driven CD 484 | * CDEvents 485 | * Would be interesting to outline or create a catalogue of quality gates. 486 | * Gather a list of what quality gates companies and teams are using in the wild. 487 | * Mini case studies for different quality gates would be interesting. 488 | * How to gather: Survey? Shoutout on channels? See action items below. 489 | * Relates to best practices 490 | * Also, would be interesting to consider how to evaluate pipelines (not testing the actual pipeline or security concerns, necessarily), but really what should a pipeline contain. Again, very much a best practices question. 491 | * What signals do we use for quality? 492 | * execution speed of pipelines, etc 493 | * How many quality checks, ideal range 494 | * how do the quality checks bucket -- interesting to see if this becomes evident once catalogue created (eg, gates in place pre and post production/rollout) 495 | * \ 496 | 497 | #### Action Items 498 | * [Justin Abrahms to create discussion on Interop SIG repo on what quality gates on being used by teams.](https://github.com/cdfoundation/sig-interoperability/discussions/83) 499 | * Kara to make sure CDF publicizes the discussion. 500 | * Kara to bring in others, from Styra, etc, to discuss how they see quality gates being used in practice. 501 | 502 | ### January 20, 2022 503 | 504 | #### Participants 505 | * Fatih Degirmenci, Ericsson Software Technology 506 | * Kara de la Marck, CDF 507 | * Jeremy Stanley, OpenDev/Zuul 508 | * Ann Marie Fred, Red Hat 509 | * Emil Backmark, Ericsson 510 | * Mattias Linnér, Ericsson 511 | * Jalander Ramagiri, Ericsson Software Technology 512 | * Ramin Akhbari, Salesforce 513 | * Erik Sternerson, doWhile 514 | * Justin Abrahms, eBay 515 | 516 | #### Agenda and Notes 517 | * Action Item Review, All 518 | * cdCon Updates, CFP, Kara de la Marck 519 | * cdCon CFP is open: https://events.linuxfoundation.org/cdcon/program/cfp/#overview 520 | - Suggestion from Kara is to submit a talk even if we don’t know if we’re allowed to travel yet 521 | * SIG Interoperability Co-chair nominations/elections, Fatih Degirmenci, All 522 | * Open Infra Summit Berlin, Jeremy Stanley 523 | * CFP for upcoming Open Infra Summit is open 524 | * There is a CI/CD track as part of summit 525 | * CFP is available here: https://cfp.openinfra.dev/app/berlin-2022 526 | * SupplyChainSecurityCon 527 | * It will be colocated in Open Source Summit NA 528 | * CFP is available here: https://events.linuxfoundation.org/open-source-summit-north-america/about/supplychainsecuritycon/ 529 | * New work around terminology for pipeline [stages](https://github.com/cdfoundation/sig-interoperability/pull/76) and [steps](https://github.com/cdfoundation/sig-interoperability/pull/81) - see links to PRs. Ann Marie Fred 530 | * Updating SIG Interoperability Roadmap, Reminder 531 | * Software Supply Chain 532 | * Standardized Metadata 533 | * Artifact Handling 534 | * Policy Driven CD 535 | * Events 536 | * Link to the document: https://docs.google.com/document/d/1uf3sb-WJUp3Acd3WYL5SvgVECHevonufJOxd6KftOxc/edit# 537 | * \ 538 | 539 | #### Action Items 540 | * \ 541 | -------------------------------------------------------------------------------- /docs/pipelines-terminology.md: -------------------------------------------------------------------------------- 1 | # Pipeline Terminology 2 | 3 | - [Introduction](#introduction) 4 | - [Pipeline Terminology](#pipeline-terminology) 5 | - [Pipeline Stages](#pipeline-stages) 6 | - [Pipeline Step Types](#pipeline-step-types) 7 | 8 | ## Introduction 9 | 10 | The purpose of this document is to collect the names and types of 11 | common pipeline stages and steps. 12 | 13 | If you are looking for the terminology used by various CI/CD tools, 14 | please consult [the tools terminology](./tools-terminology.md) document 15 | which is located next to this document. 16 | 17 | ## Pipeline Terminology 18 | 19 | ### Pipeline Stages 20 | 21 | The list below is an attempt to create a mapping of common names for Stages, where a Stage is defined here as the unit of work one degree smaller than a Pipeline. (The effort of proposing a common vocabulary across CI/CD Tools and Technologies is not yet performed, but we'll use the most common term from the table above as the working term.) 22 | 23 | While CI/CD Tools and Technologies generally give developers broad leeway in naming and implementing their Stages, agreeing upon some common terms will help develop more pluggable Pipelines. 24 | 25 | The concepts below can be re-ordered in Pipeline implementations. For example, it is often the case that software linting (logically a test) is done prior to the Build Stage. Also, deployment to a staging environment is often done prior to the Release Stage, while the deployment for production often happens after the Release Stage. 26 | 27 | In Pipeline implementations, there may also be other Stages preceding or following the ones listed below. 28 | 29 | In the lists and table below, Software Artifacts includes: Documentation Source Files, Source Code, Baseline/Composition/Dependency Information, Infrastructure as Code. 30 | 31 | "Software Source" refers to human-readable source files that are inputs to the pipeline, such as: Source Code, Configuration Files, Documentation Source Files, Declared Dependencies, Baseline/Composition Information (i.e. lock files in source control) 32 | 33 | "Binary Source" refers to executables that are inputs to the pipeline, such as: Executable Software Dependencies, Container Images, Virtual Machine Images 34 | 35 | "Generated Software" refers to human-readable files that are outputs of the pipeline, such as: Compiled Software, Generated Configuration Files, Compiled Documentation, Baseline/Composition Information generated by the pipeline. 36 | 37 | "Generated Binaries" refers to executables that are outputs of the pipeline, such as: Executable Software, Container Images, Virtual Machine Images 38 | 39 | #### Any Stage 40 | * Semantics: Some inputs and outputs are used across any and all stages. They're listed here once, rather than repeating them for each stage. 41 | * Aliases: N/A 42 | * Inputs: Secrets, Pipeline Environment, Pipeline Workspace, Pipeline Utility Tools 43 | * Outputs: Stage Results and Return Codes, Logs 44 | 45 | #### Build Stage 46 | * Semantics: Download, retrieve, assemble, and/or compile software into an executable and testable format. Download, retrieve, assemble, and/or compile documentation into a consumable format. 47 | * Aliases: Compile 48 | * Inputs: Software Source, Binary Source 49 | * Outputs: Generated Software, Generated Binaries 50 | * Other Results and Side Effects: The Build stage may also capture and store point-in-time details about the pipeline environment and tools (compiler versions, package manager versions, task container versions in tekton, OS versions etc.). While the pipeline configuration should ideally be in source code, in reality some settings will likely depend on external factors. Storing this information in an immutable data store facilitates debugging, rebuilds, pipeline verification, audit records, and forensics. 51 | 52 | #### Test Stage 53 | * Semantics: Test, scan, verify, and lint software and documentation. 54 | * Aliases: Verify 55 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries 56 | * Outputs: Test/Lint/Scan Records, Test/Lint/Scan Reports, Test/Lint/Scan Coverage Reports 57 | * Other Results and Side Effects: N/A 58 | 59 | #### Release Stage 60 | * Semantics: Package, version, sign, and publish software artifacts and documentation. 61 | * Aliases: Deliver, Publish 62 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Release Approvals 63 | * Outputs: Release Records, Release Reports, Generated Software, Generated Binaries 64 | * Other Results and Side Effects: Documentation and Software: packaged, signed, and published to a repository. 65 | 66 | #### Deploy Stage 67 | * Semantics: Deploy software artificats and documentation to any environment other than the pipeline environment. Verify successful deployment. 68 | * Aliases: Install 69 | * Inputs: Deployment Configuration, Software Source, Binary Source, Generated Software, Generated Binaries, Deployment KPIs 70 | * Outputs: Deployment Records, Deployment Reports, Secrets to access deployed resources 71 | * Other Results and Side Effects: Documentation hosted in a review, staging or production environment. Software running in a review, staging or production environment. Deployment KPIs might influence how the deployment proceeds; for example, for Canary or Blue/Green deployments. 72 | 73 | #### Operations Stage 74 | * Semantics: monitoring of deployed assets 75 | * Aliases: Steady state, Production, Production Management 76 | * Inputs: Deployment and Monitoring Configuration, Artifact Versions, Operational Metrics, Vulnerability and Security Updates 77 | * Outputs: Operational Metrics, Alerts, Bug Reports, Logs 78 | * Other Results and Side Effects: Automated Rollbacks, Vulnerability Mitigation 79 | via Rebuild / Redeploy, Human Interventions 80 | 81 | #### Inputs and Outputs for Pipeline Stages 82 | 83 | | Stage Name | Software Source | Binary Source | Generated Software | Generated Binaries | Secrets | Pipeline Environment | Pipeline Workspace | Return Codes | Results, Records and Reports | Logs | 84 | | :--------: | ------------------ | ---------------- | ---------------------- | ------------------- | ------- | ----------------- | ---------------- | ------------ | ---------------------------- | ---- | 85 | | Build | I | I | O | O | I | I | I | O | O | O | 86 | | Test | I | I | I | I | I | I | I | O | O | O | 87 | | Release | I | I | I, O | I, O | I | I | I | O | O | O | 88 | | Deploy | I | I | I | I | I, O | I | I | O | O | O | 89 | | Operations | I | I | I | I | I | I | N/A | O | O | O | 90 | 91 | ### Pipeline Step Types 92 | 93 | The table below is an attempt to create a mapping of common names for the various types of Pipeline Steps (the unit of work two degrees smaller than a Pipeline). (The effort of proposing a common vocabulary across CI/CD Tools and Technologies is not yet performed, but we'll use the most common term from the table above as the working term.) 94 | 95 | While CI/CD tools and technologies generally give developers broad leeway in naming and implementing their Pipeline Steps, agreeing upon some common terms will help develop more pluggable pipelines. This list is not meant to be exhaustive. 96 | 97 | Each type of Pipeline Step will generally have several implementations that are tool specific. For example, Source will have implementations for various Source Code Management (SCM) tools. Publish will have implementations for each type of repository, and so on. 98 | 99 | #### Any Step 100 | * Semantics: Some inputs and outputs are used across any and all steps. They're listed here once, rather than repeating them for each step. 101 | * Aliases: N/A 102 | * Inputs: Secrets, Pipeline Environment, Pipeline Workspace, Parameters for the Step 103 | * Outputs: Return Codes, Results, Records and Reports, Logs 104 | * Other Results and Side Effects: N/A 105 | 106 | #### Setup 107 | * Semantics: Provision pipeline resources, set up the pipeline workspace. It's possible to have one Setup step at the beginning of each pipeline run, and additional Setup steps as the pipeline progresses. 108 | * Aliases: Initialize, Start, Prepare, Workspace, Orchestrate 109 | * Inputs: Pipeline Request Parameters, Pipeline Container Image Name and Version 110 | * Outputs: Secrets, Pipeline Environment, Pipeline Workspace 111 | * Other Results and Side Effects: May set up persistent storage or another method for pipeline steps to share inputs and outputs with each other. 112 | 113 | #### Source 114 | * Semantics: Download, retrieve or copy software, images, and documentation into the pipeline workspace. Fetch configuration data. 115 | * Aliases: Clone, Fetch 116 | * Inputs: Source Code Reference (Repository, Branch, Commit) 117 | * Outputs: Software Source, Binary Source 118 | * Other Results and Side Effects: N/A 119 | 120 | #### Secret Detection 121 | * Semantics: Detect secrets in the source code, other software, or documentation. Examples include passwords, SSH keys, API keys, and so on. 122 | * Aliases: N/A 123 | * Inputs: Source Code Reference (Repository, Branch, Commit), Software Source, Binary Source 124 | * Outputs: Secret Detection Report 125 | * Other Results and Side Effects: Revoked Secrets 126 | 127 | #### Build 128 | * Semantics: Assemble and/or compile software and documentation into an executable and usable format. 129 | * Aliases: Compile, Install, Assemble, Generate 130 | * Inputs: Software Source, Binary Source 131 | * Outputs: Generated Software, Generated Binaries 132 | * Other Results and Side Effects: N/A 133 | 134 | #### Dependency Discovery 135 | * Semantics: Perform deep discovery to identify all dependencies (including transitive dependencies) in the software and documentation as packaged. 136 | * Aliases: Dependencies 137 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries 138 | * Outputs: Dependency List/Graph 139 | * Other Results and Side Effects: N/A 140 | 141 | #### Remediate 142 | * Semantics: Find and automatically fix known vulnerabilities for application package dependencies, container base images and os packages. 143 | * Aliases: Fix, Update 144 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Source Code Reference (Repository, Branch, Commit), Dependency List/Graph 145 | * Outputs: Remediated Software or Documentation, Container Images, Binaries, Source Code Reference (Repository, Branch, Commit), Dependency List/Graph 146 | * Other Results and Side Effects: May also update the Source Code Repository with new dependencies, create a pull request with the updates, use APIs to request an update, open an issue requesting the updates. In the case of mutable infrastructure, this step could update a running system. 147 | 148 | #### Test 149 | * Semantics: Run a test suite. Examples includes unit tests, integration tests, acceptance tests, performance tests, canary tests, A/B tests, smoke tests, code coverage checks. 150 | * Aliases: Validate 151 | * Inputs: Any 152 | * Outputs: Test Results, Test Reports, Test Coverage Reports 153 | * Other Results and Side Effects: N/A 154 | 155 | #### Scan 156 | * Semantics: Use a tool to do verification of software and documenation other than testing. Examples include static code analysis, linting, checking for known vulnerabilities in code or binaries, dynamic security scans, license checks, and code smells. 157 | * Aliases: Check 158 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Dependency List/Graph 159 | * Outputs: Scan Results, Scan Reports, Scan Coverage Reports 160 | * Other Results and Side Effects: N/A 161 | 162 | #### Bill of Materials 163 | * Semantics: Create a Software Bill of Materials (SBoM) for a given repository that captures pedigree of all the dependencies and is collected at different granularities. 164 | * Aliases: BOM, SBOM 165 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Dependency List/Graph, Packaged Artifacts 166 | * Outputs: Build BOM 167 | * Other Results and Side Effects: N/A 168 | 169 | #### Package 170 | * Semantics: Create the software artifact(s) that will be published. To specify the version of the software this pipeline is producing, the package step(s) may use a software version that's specified in the source code, or calculate and automatically update the version using semver logic. 171 | * Aliases: Containerize 172 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Dependency List/Graph 173 | * Outputs: Packaged Artifacts (Software, Documentation or Binaries), Container Images, Image Tags, Image Digests, Archives 174 | * Other Results and Side Effects: N/A 175 | 176 | #### Tag 177 | * Semantics: Annotate source code, artifacts/images, and so on with information, such as the version number and a description. 178 | * Aliases: Annotate, Version 179 | * Inputs: Source Code Reference (Repository, Branch, Commit), Software Source, Binary Source, Generated Software, Generated Binaries 180 | * Outputs: Tag/annotation metadata 181 | * Other Results and Side Effects: Tags/annotations have been added to the software. 182 | 183 | #### Sign 184 | * Semantics: Use a cryptographic method to authenticate the software. The signature may also include information about the source of the software, how or where it was built, and what level of approval it has received (staging, production, etc.). 185 | * Aliases: N/A 186 | * Inputs: Packaged Artifacts 187 | * Outputs: Signed Artifacts, Signing Record(s) 188 | * Other Results and Side Effects: N/A 189 | 190 | #### Policy 191 | * Semantics: Verifies that policies are followed, for example: software is from a trusted source, source repositories are configured correctly, Kubernetes manifests are configured securely, dependencies are signed, code standards are followed, code reviews are completed, there is a secure chain of custody, or appropriate work items or change requests are associated with the change. 192 | * Aliases: Check, Provenance 193 | * Inputs: Policies, Outputs of other steps 194 | * Outputs: Policy and/or Provenance Reports 195 | * Other Results and Side Effects: Side effects could include blocking a PR/commit so it can't be merged, discarding or approving an artifact/image. 196 | 197 | #### Publish 198 | * Semantics: Upload software artifacts and documentation to another repository. May also update catalogs, mirrors, release notes, etc. 199 | * Aliases: Push, Upload, Release 200 | * Inputs: Packaged (Signed) Artifacts 201 | * Outputs: Repository URLs 202 | * Other Results and Side Effects: Repositories are updated. 203 | 204 | #### Provision 205 | * Semantics: Request that a new physical or virtual server, network, or other resource be allocated or created. Examples include a test cluster or object storage. 206 | * Aliases: Obtain, Request, Allocate 207 | * Inputs: Resource Request Parameters 208 | * Outputs: Provisioned Resources (with connection info) 209 | * Other Results and Side Effects: Resources are provisioned. 210 | 211 | #### Deploy 212 | * Semantics: Make changes to any environment other than the pipeline environment. Configure the environment. Deploy dependencies, software artificts and/or documentation. 213 | * Aliases: Install, Configure 214 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Dependency List/Graph, Packaged Artifacts, Provisioned Resources 215 | * Outputs: Routes to Deployments (with connection info). Deployment Records. Secrets to access deployed resources. 216 | * Other Results and Side Effects: Software running in another environment. Documentation hosted in another environment. 217 | 218 | #### Verify Deployment 219 | * Semantics: Verify successful deployment of software or documentation. 220 | * Aliases: Smoke Test 221 | * Inputs: Provisioned Resources, Routes to Deployments, Secrets to access deployed resources. 222 | * Outputs: Deployment Verification Results, Deployment Verification Records 223 | * Other Results and Side Effects: N/A 224 | 225 | #### Analyze 226 | * Semantics: Perform additional processing and analytics based on the results of a previous activity. 227 | * Aliases: Metrics, Score, Grade, Parse 228 | * Inputs: Any 229 | * Outputs: Analysis Results, Analysis Reports 230 | * Other Results and Side Effects: N/A 231 | 232 | #### Message 233 | * Semantics: Send a message to another system; for example, a Slack message or an Email. This is different from "Create Request" because the pipeline doesn't need to store a link/handle for the message. 234 | * Aliases: N/A 235 | * Inputs: Output of previous steps. 236 | * Outputs: Message Return Code / Results 237 | * Other Results and Side Effects: Message sent. 238 | 239 | #### Create Request 240 | * Semantics: Create a request in another system; for example, create a Change Request that must be approved for a deployment to production. This is different from "Message" because we need to get a link/reference for the new request, and store it, so we can potentially update it later. 241 | * Aliases: Approval, Ticket, Issue, Work Item 242 | * Inputs: Source Code Reference (Repository, Branch, Commit), Link to Previous Work Item, Provisioned Resources, Routes to Deployments 243 | * Outputs: Request Return Code/Results, Link to New Request 244 | * Other Results and Side Effects: Request created. 245 | 246 | #### Update Record 247 | * Semantics: Update a record in another system; for example, update and close a Change Request after a deployment to production; or, update a Github issue with the results of a policy check. 248 | * Aliases: Editor 249 | * Inputs: Source Code Reference (Repository, Branch, Commit), Link to Previous Request, Provisioned Resources, Routes to Deployments 250 | * Outputs: Update Return Code/Results, Link to Request 251 | * Other Results and Side Effects: Request record updated. 252 | 253 | #### Run 254 | * Semantics: Run a script or program that doesn't fall into one of the other categories. Often executes in another container. 255 | * Aliases: Execute 256 | * Inputs: Software Source, Binary Source, Generated Software, Generated Binaries, Packaged Artifacts, Provisioned Resources, Routes to Deployments 257 | * Outputs: Output or results of the script or program. 258 | * Other Results and Side Effects: Whatever the script or program has done. 259 | 260 | #### Record Results 261 | * Semantics: Record and report pipeline results and compliance evidence. Store pipeline artifacts for long-term archival. 262 | * Aliases: Audit, Attestation, Evidence, Report 263 | * Inputs: Any 264 | * Outputs: Compliance Reports, Archive Files, Return Code/Results 265 | * Other Results and Side Effects: Results, logs, reports, compliance evidence, and other pipeline artifacts are uploaded and/or archived. 266 | 267 | #### Cleanup 268 | * Semantics: Release pipeline resources, de-provision environments, delete pipeline workspace and pipeline container(s). 269 | * Aliases: Finalize, Finish 270 | * Inputs: Pipeline Environment, Pipeline Workspace, Provisioned Resources, Routes to Deployments 271 | * Outputs: Return Code/Results 272 | * Other Results and Side Effects: Deleted Pipeline Environment and Pipeline Workspace, De-provisioned Resources, Deleted Deployments 273 | 274 | #### Inputs and Outputs for Pipeline Steps 275 | 276 | The inputs and outputs listed in this table are the ones that are used by more than one step. These inputs and outputs need to be in a location and/or format that the pipeline steps expect so they can be processed correctly. 277 | 278 | With the exception of the Setup and Cleanup steps, all steps have the following inputs: Secrets, Pipeline Environment, Pipeline Workspace, Parameters for the Step; and the following outputs: Return Codes, Results, Records and Reports, Logs. 279 | 280 | | Step Name | Software Source | Binary Source | Generated Software | Generated Binaries | Source Code Reference | Dependency List/Graph | Test Coverage Reports | Packaged Artifacts | Provisioned Resources | Routes to Deployments | Request Link | 281 | | :-------: | ------------------ | ---------------- | ---------------------- | ------------------- | ------------------------------ | --------------------- | --------------------- | ------------------ | --------------------- | --------------------- | -------------- | 282 | | Setup | | | | | | | | | O | | | 283 | | Source | O | O | | | I | | | | | | | 284 | | Secret Detection | I | I | | | I | | | | | | | 285 | | Build | I | I | O | O | | | | | | | | 286 | | Dependency Discovery | I | I | I | I | | O | | | | | | 287 | | Remediate | I, O | I, O | I, O | I, O | I, O | I, O | | | | | | 288 | | Test | I | I | I | I | | | O | I | I | I | | 289 | | Scan | I | I | I | I | | I | | | | | | 290 | | Bill of Materials | I | I | I | I | | I | | | | | | 291 | | Package | I | I | I | I | | I | | O | | | | 292 | | Tag | I | I | I | I | I | | | | | | | 293 | | Sign | | | | | | | | I, O | | | | 294 | | Policy | I | I | I | I | I | I | I | I | I | I | I | 295 | | Publish | | | | | | | | I | | | | 296 | | Provision | | | | | | | | | O | | | 297 | | Deploy | I | I | I | I | | I | | I | I | O | | 298 | | Verify Deployment | | | | | | | | | I | I | | 299 | | Analyze | I | I | I | I | I | I | I | I | I | I | I | 300 | | Message | | | | | I | | I | I | I | I | | 301 | | Create Request | | | | | I | | | | I | I | I, O | 302 | | Update Record | | | | | I | | | | I | I | I, O | 303 | | Run | I | I | I | I | | | | I | I | I | | 304 | | Record Results | I | I | I | I | I | I | I | I | I | I | I | 305 | | Cleanup | | | | | | | | | I | I | | 306 | -------------------------------------------------------------------------------- /docs/policy_driven_cd.md: -------------------------------------------------------------------------------- 1 | # Policy Driven CD 2 | 3 | ## Quick links 4 | 5 | * [Introduction](#Introduction) 6 | * [Policy Types](#Policy-Types) 7 | * [Open Source Policy Frameworks](#Open-Source-Policy-Frameworks) 8 | * [Open Policy Agent](#Open-Policy-Agent) 9 | * [ONAP Policy Framework](#ONAP-Policy-Framework) 10 | * [Approaches to Policy](#Approaches-to-Policy) 11 | * [Communities](#Communities) 12 | * [Jenkins](#Jenkins) 13 | * [Spinnaker](#Spinnaker) 14 | * [Tekton](#Tekton) 15 | * [Ortelius](#Ortelius) 16 | * [DeployHub Pro](#DeployHub-Pro) 17 | * [Zuul](#Zuul) 18 | * [Users](#Users) 19 | * [eBay](#eBay) 20 | * [Ericsson](#Ericsson) 21 | * [Challenges](#Challenges) 22 | * [Terminology](#Terminology) 23 | * [Best Practices](#Best-Practices) 24 | * [Interoperability](#Interoperability) 25 | * [References](#References) 26 | 27 | ## Introduction 28 | 29 | TBD 30 | 31 | ## Policy Types 32 | 33 | TBD 34 | 35 | ## Open Source Policy Frameworks 36 | 37 | ### Open Policy Agent 38 | 39 | Open Policy Agent is an infrastructure agnostic policy engine with the mission of decoupling decisions 40 | about policy from other application business logic, via "policies as code". 41 | 42 | Policies are expressed in a language called Rego which is supported via: 43 | 44 | * An online playground: https://play.openpolicyagent.org/ 45 | * IDE integrations (e.g. [vscode](https://marketplace.visualstudio.com/items?itemName=tsandall.opa)) 46 | * [Testing capabilities](https://www.openpolicyagent.org/docs/latest/policy-testing/) 47 | * [Command line REPL](https://www.openpolicyagent.org/docs/latest/#2-try-opa-eval) 48 | 49 | ### ONAP Policy Framework 50 | 51 | TBD 52 | 53 | ## Approaches to Policy 54 | 55 | ### Communities 56 | 57 | #### Jenkins 58 | 59 | Jenkins Pipeline has a check for insecure pipeline interpolation. This check is run before the pipeline and is not yet integrated into a policy, so it will not block a pipeline from running. If the check fails, a warning will be shown. 60 | 61 | There is interest within the Jenkins community to support OPA. 62 | 63 | #### [CloudBeees Pipeline Policies Plugin](https://docs.cloudbees.com/docs/admin-resources/latest/pipelines/pipeline-policies) 64 | 65 | This plugin enables pipeline policies. Currently, the plugin has one rule to enforce timeouts. Administrators can add multiple policies to govern pipeline execution. Each policy can have multiple rules for limiting timeouts either for the entire pipeline, paused actions, or for specific agents. Each pipeline policy can be set to issue a warning or to fail and have the pipeline stop executing. 66 | 67 | The intention is to add more policy rules in the future. 68 | 69 | #### Spinnaker 70 | 71 | TBD 72 | 73 | * The Armory flavor of Spinnaker [supports OPA](https://docs.armory.io/docs/armory-admin/policy-engine-enable/) 74 | 75 | #### Tekton 76 | 77 | A few ways that Tekton could integrate with Policy frameworks: 78 | 79 | * Enforcing policies via kubernetes webhooks (e.g. looking at TaskRuns and PipelineRuns), 80 | and either: 81 | * Preventing them from executing when policies are violated 82 | * Mutating them to enforce policies 83 | * Using policies to generate Pipelines and Tasks (e.g. express CD pipelines completely 84 | via policy) 85 | * Using [when expressions](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#guard-task-execution-using-whenexpressions) 86 | as gates to control execution of Tasks in a Pipeline 87 | * [Tekton Chains](https://github.com/tektoncd/chains) has a goal to store trusted 88 | information about executions and policies could be expressed against this 89 | * Tekton Triggers has support for [interceptors](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#interceptors) 90 | for filtering, with built in support for CEL and extensibility which could support 91 | [Rego](https://github.com/tektoncd/triggers/issues/484) 92 | 93 | An interesting question to answer about policy is do you want it to be _reactive_ or 94 | _proactive_, e.g. do you want to find out that you are violating a policy, or do you 95 | want to use a policy to decide what you do. 96 | 97 | #### Ortelius 98 | Ortelius, serving as a centralized catalog for microservice deployment metadata and relationships is relatively unrestricted with some built-in guardrails. 99 | 100 | * License policy would ensure all components for an application version conform to an approved list of licenses. Ortelius would enforce that application versions from consuming components with unapproved licenses would not be deployed. 101 | 102 | * CVE policy would ensure all components for an application version conform to a risk level. Ortelius would enforce that application versions consuming components with a high risk level would not be deployed. 103 | 104 | * Configuration policy would be used to ensure specific configurations are in place for the application versions, component versions and environment combination. 105 | 106 | For example, does the cluster have enough nodes in it. 107 | 108 | Ortelius would enforce that the configuration is in conformance and prevent the application version from being deployed if there is a policy violation. 109 | 110 | #### DeployHub Pro 111 | 112 | A few ways that DeployHub Pro could integrate with Policy frameworks: 113 | 114 | * Authorization policy would be used to validate who can do what preventing unauthorized actions from happening. 115 | 116 | For example, which users can update a component or which group can execute a deployment. 117 | 118 | * Approved Component policy would be used to ensure all components for an application are on the "Approved to Use" list. This policy would allow new unapproved components in development but restricted for testing and production. DeployHub Pro would enforce the consumption of the components by applying the appropriate policy for the pipeline stage (dev, test, prod). 119 | 120 | * License policy would ensure all components for an application version conform to an approved list of licenses. DeployHub Pro would enforce that application versions from consuming components with unapproved licenses would not be deployed. 121 | 122 | * CVE policy would ensure all components for an application version conform to a risk level. DeployHub Pro would enforce that application versions consuming components with a high risk level would not be deployed. 123 | 124 | * Duplicate Component policy would be used to minimize the copying of code instead of it being made available as reusable code. DeployHub Pro would enforce that application versions consuming components do not have copied code in a component and would prevent the application version from being deployed. 125 | 126 | * SLO/SLI policy would be used as a reactive policy to revert a deployment to its previous version if the policy has been violated. DeployHub Pro would redeploy the previous version of the application to the environment. 127 | 128 | * Configuration policy would be used to ensure specific configurations are in place for the application versions, component versions and environment combination. 129 | 130 | For example, does the cluster have enough nodes in it. 131 | 132 | DeployHub Pro would enforce that the configuration is in conformance and prevent the application version from being deployed if there is a policy violation. 133 | 134 | #### Zuul 135 | 136 | Policy enforcement in Zuul is achieved through layered management of job definitions, and their mapping to build triggers via project pipelines. Because this configuration can be distributed across any of the Git repositories included in a tenant, even speculatively incorporating configuration from proposed changes not yet merged, people who control the content of those repositories or who can propose changes for them have the ability to influence what jobs are run and what those jobs do. In order to provide a central means of administration, any of this configuration can also reside in trusted repositories under the control of tenant managers, and is immutable from the perspective of untrusted repositories, or at least designed to limit what variables may be externally overridden. The upshot of this model is that tenant managers have the ability to specify particular jobs which must run and succeed before changes can merge, or mandate that certain playbooks are included within jobs, in addition to those which the maintainers of untrusted repositories might wish to add. 137 | 138 | While Zuul configuration can be organized in a variety of ways to provide policy enforcement, the documentation recommendeds a popular arrangement referred to as the Project Testing Interface: https://zuul-ci.org/docs/zuul/howtos/pti.html 139 | 140 | ### Users 141 | 142 | #### eBay 143 | 144 | The approach to policy at eBay is more of a badge system. Badges are awarded by a central authority and events are produced based on this so other systems could subscribe to them. 145 | We are trying to make sure that as the manifest for a particular release is moving from environment to environment with ultimate goals to reach production. 146 | They achieve certain things along the way - those things are making sure a project or an application has a CD pipeline defined (build/unit tests/integration tests/security tests). 147 | All of these basically become badges so a manifest of an application that's a candidate for release receives along the way. 148 | For example; when unit tests finish, they report back to system and the system takes the manifest id, awarding a badge and so on and so forth. 149 | When they are ready to deploy to staging environment, it requires manifests to have certain set of badges to in order to be deployed. 150 | Otherwise, deployment is denied. 151 | This ensures things are done as per the company policy for different environments. (feature environment, staging environment, pre-production environment, production environment) 152 | 153 | This is similar to gating - gate allows or prevents deployment of a certain application version to different environments based on badges. 154 | 155 | #### Ericsson 156 | 157 | The use case at Ericsson is pretty similar to eBay. 158 | At Ericsson, the term " "Confidence Levels" are used. These confidence levels are applied when an artifact passes certain type of tests, gaining confidence levels. These confidence levels are carried by events, triggering actual deployments. 159 | In this case, the "Deployment system" doesn't search for badges but events are the main medium to trigger stuff. 160 | 161 | ## Challenges 162 | 163 | ### Terminology 164 | 165 | eBay: Badges are used to enforce policies 166 | Ericsson: Confidence Levels are used to enforce policies 167 | 168 | ### Best Practices 169 | 170 | TBD 171 | 172 | ### Interoperability 173 | 174 | TBD 175 | 176 | ## References 177 | 178 | TBD -------------------------------------------------------------------------------- /docs/roadmap.md: -------------------------------------------------------------------------------- 1 | # CDF SIG Interoperability Roadmap 2 | 3 | ## Quick Links 4 | 5 | - [Overview](#overview) 6 | - [Charter](#charter) 7 | - [Outcomes](#outcomes) 8 | - [Roadmap](#roadmap) 9 | - [Contributors](#contributors) 10 | 11 | ## Overview 12 | 13 | This document outlines the roadmap for the Continuous Delivery Foundation (CDF) 14 | Interoperability Special Interest Group (SIG). The roadmap represents the 15 | initiatives of the open source collaborations. The roadmap does not specify 16 | timelines or delivery dates, but rather uses time horizons (now, next, later). 17 | 18 | ## Charter 19 | 20 | The CDF Interoperability SIG works to solve the problems of making CI/CD 21 | software tools interoperable and interchangeable.  22 | 23 | Software interoperability is essential to drive CI/CD tool adoption as well as 24 | promote innovation in the industry. To achieve this, the SIG will strive to 25 | collaboratively develop and expedite well defined definitions, interfaces, and 26 | reusable software libraries, services and applications.  27 | 28 | ## Outcomes  29 | 30 | The group will work towards a number of outcomes  31 | 32 | 1. **Knowledge Transfer of CI/CD Tools & Technologies:** We share information 33 | about open source CI/CD tools, infrastructure and frameworks. 34 | 2. **End User Requirements:** We capture actual ways end users are using tools, 35 | the problems they are trying to solve, the pain points they are experiencing 36 | particularly around tool integration.  37 | 3. **Shared Reference Terminology:** We work on establishing shared vocabulary 38 | since CI/CD practitioners have many tools and technologies at their disposal 39 | but it is often the case that what we call a pipeline in today’s tool of 40 | choice is not called the same thing in the tool we use tomorrow.  41 | 4. **Interoperable Tools:** It is almost always the case that the CI/CD systems 42 | organizations employ evolve continuously, new tools are brought in and others 43 | phased out, making it crucial for users to have tool interoperability in 44 | order to ease the effort to get the best out of the systems and establish 45 | end-to-end flow of software with the help of well-defined interfaces, 46 | reusable libraries, services, and applications. 47 | 5. **Standardized Frameworks** 48 | 6. **Promote Best Practices** 49 | 50 | ## RoadMap 51 | 52 | ![](https://lh5.googleusercontent.com/5F-b4dHm1MMqn47PNzMx9Br7h6N62fEnZU3xp60E9LksEo-MmOK8Ok0PqjyAet4oevSk4vXcgfdi7wg8V4gRuvklCDoO57km-r6DKZS7w4IFhlquyq4_KCHrcYVZNXR1EIRTyDxO) 53 | 54 | Reference: Janna Bastow (https://twitter.com/simplybastow/status/1168531737766432768?s=20) 55 | 56 | 57 | ### Completed 58 | 59 | #### Knowledge transfer of CI/CD Tools and Technologies 60 | 61 | The CDF SIG holds regular presentations to enable knowledge sharing about CI/CD 62 | Tools & Technologies, infrastructure, and frameworks. 63 | 64 | Presentations of the following tools and technologies are completed. 65 | 66 | * [Tekton](https://tekton.dev/) 67 | * [Keptn](https://keptn.sh/) 68 | * [Zuul](https://zuul-ci.org/) 69 | * [Eiffel](https://eiffel-community.github.io/) 70 | * [Jenkins X](https://jenkins-x.io/) 71 | * [Flagger](https://flagger.app/) 72 | * [Tekton Catalog and Hub](https://tekton.dev/) 73 | * [Argo Rollouts](https://argoproj.github.io/argo-rollouts/) 74 | 75 | #### Documenting and Publishing CI/CD Vocabulary 76 | 77 | The vocabulary/terminology used by various CI/CD tools & technologies have been 78 | documented in [SIG Interoperability repository](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md) 79 | and an article is contributed to [CDF Newsletter](https://cd.foundation/blog/2020/04/24/how-the-cdf-is-establishing-a-shared-vocabulary-for-the-industry/). 80 | 81 | ### Now  82 | 83 | #### Knowledge transfer of CI/CD Tools and Technologies 84 | 85 | The CDF SIG will continue working on knowledge transfer of CI/CD Tools and 86 | Technologies in order to identify trends and explore further cross community 87 | collaboration opportunities. 88 | 89 | Upcoming presentations include 90 | 91 | * Jenkinsfile Runner 92 | * Spinnaker 93 | * Lighthouse 94 | 95 | #### End User Case Studies 96 | 97 | End users will share use cases, challenges, and the work they are doing within 98 | their organizations with the community in order to enable dialog and further 99 | collaboration. 100 | 101 | * eBay 102 | 103 | #### Identify Focus Areas 104 | 105 | Interoperability in CI/CD tools and technologies means different things to 106 | different people depending on the activities they are performing in their CI/CD 107 | workflows, tools and technologies they are using, integration points they may 108 | have within their systems and so on. Some examples to this are 109 | 110 | * An organization employing more than one technology to establish and run CI/CD 111 | pipelines due to different capabilities provided by the tools and the 112 | organization wants to have means to construct these pipelines in a 113 | standardized way 114 | * An organization with multiple subunits where different components are 115 | developed and delivered needs to have ways to connect the CI/CD pipelines 116 | constructed using different tools within sub-units in a standardized way to 117 | establish end to end traceability 118 | * An organization with CI/CD workflows spanning across multiple units, internal 119 | and/or external, wants to visualize what is going on within CI/CD workflow any 120 | point in time and in a real time or historical manner 121 | * An organization with the aim to actively engage with its customers in the 122 | product lifecycle and receive continuous feedback from their integration and 123 | delivery flows. 124 | * An organization with CI/CD system would like to migrate to different set of 125 | tools without developing new pipelines from scratch 126 | * An organization that want to integrate other tools such as Software 127 | Configuration Management Systems (SCM), Artifact Repository Managers (ARM), 128 | and so on with CI/CD tools they are using in a ways that is agnostic to SCM, 129 | ARM, and CI/CD tools they are using so they can abstract the logic away from 130 | the tools and focus on software flow 131 | 132 | As it can be seen from the examples above, there are different needs that need 133 | to be addressed. Tackling these in a more structured manner would make it easier 134 | to get the collaboration going. To enable this, the SIG started identifying few 135 | focus areas based on the conversations happening within the SIG. 136 | 137 | Some of the identified areas are 138 | 139 | * **Events in CI/CD**: Events are everywhere and new tools and technologies, 140 | including the ones within CI/CD domain, already adapted this such as 141 | [Tekton](https://github.com/tektoncd/triggers), [Keptn](https://keptn.sh/), 142 | and [Eiffel](https://eiffel-community.github.io/). 143 | * **Reusable Libraries**: There are various libraries that are developed by 144 | different communities such as [go-scm](https://discourse.drone.io/t/go-scm-jenkins-x-tekton-and-cdf/6698). 145 | SIG and CDF could provide home for collaboration on reusable libraries, 146 | helping with further development, coordination, and sharing of them. 147 | 148 | #### Establish Workstreams 149 | 150 | The way the SIG could enable further collaboration and focused work on the 151 | areas is identified as introducing workstreams within the SIG, each working 152 | on a specific area. The project and user representatives who take part in the 153 | SIG can volunteer as workstream lead or contributor and work on the areas in a 154 | more focused and structured way, continuously sharing the progress with the rest 155 | of the SIG. The expectations from workstreams could vary depending on the area; 156 | they could work on collecting the state of things in a specific area from within 157 | the ecosystem and contribute that to the domain or come up with a proposal to 158 | address some of the needs in a more structured way in order to socialize their 159 | ideas further and increase the awareness. This could also help us to present 160 | ideas per area on CDF TOC level in order to gather feedback. 161 | 162 | The process around establishing, running, and retiring SIG workstreams is 163 | currently being documented in [SIG Interoperability repository](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/workstream-governance.md). 164 | 165 | ### Next 166 | 167 | #### Establishing Shared Terminology 168 | 169 | SIG Vocabulary document, "The Rosetta Stone", makes it possible for the CI/CD 170 | ecosystem to collect and share the terminology used by different CI/CD tools 171 | and technologies in one place, making it easier for the community to see the 172 | commonalities and differences. 173 | 174 | The Rosetta Stone could be seen as the basis for getting the dialog going about 175 | the benefits of establishing (defacto) terminology for CI/CD domain and 176 | drive the standardization within interoperability further. 177 | 178 | Possible steps to achieve this goal are 179 | 180 | * Include additional tools and technologies within the document (12 CI/CD tools 181 | and technologies are included in the document) 182 | * Continue highlighting this work and get help from others to increase the 183 | participation 184 | * Demonstrate the benefits clearly 185 | * Stress the importance of doing this work in a real neutral place where 186 | project and user representatives could take part 187 | * Prioritize things that matter (interoperability is more key than common 188 | language) 189 | * Establish process around how to start and drive the work on standardization 190 | * Establish de facto terms  191 | 192 | Some of the challenges we foresee are 193 | 194 | * Friction for maintainers to change terminologies and whether we can 195 | simplify this 196 | * Companies will have own internal (proprietary) tools and terminology 197 | 198 | #### Additional Focus Areas 199 | 200 | In addition to the focus areas SIG identified and started working, various 201 | other areas are also highlighted as potential areas to work. 202 | 203 | * **Pipeline Data for Traceability and Visualization**: How can we propagate 204 | data from our CI/CD tools in a way that external tools can consume it 205 | regardless of what CI/CD tool created the data? 206 | * **Pipeline standardization/languages** 207 | 208 | * **Integration with the tools that are not traditionally seen as CI/CD tools** 209 | 210 | #### Standardized Frameworks 211 | 212 | As a preparation for defining interfaces, libraries and services, first we must 213 | collect, discuss, and build an understanding of common tasks solved in CI/CD 214 | workflows. This list would contain tasks as listed below. 215 | 216 | * **Merge source code**: This task is typically not performed by the CI/CD 217 | pipelines themselves, unless automatic baseline uplifts are performed in 218 | those systems, but it serves as the trigger for the CI pipeline/workflow. 219 | * **Source code tests**: Typically Lint tests or other static code analysis 220 | done before building the source code. 221 | * **Build**: Producing artifacts from the source code. Potentially including 222 | other source code repositories, libraries and pre-built artifacts from other 223 | sources. 224 | * **Binary tests**: Testing the built binary. In a Kubernetes environment this 225 | is normally done after the deployment step below, but in VMs and legacy 226 | environments this is typically done as the first thing after the build. 227 | * **Configuration change**: The availability of a new software artifact or a new 228 | configuration (e.g. changed environment variables, arguments, etc.) lead to a 229 | configuration change. This configuration change is the trigger for a CD 230 | workflow. In a GitOps approach, this configuration change could be a commit or 231 | a Pull Request. 232 | * **Pre-deployment**: Before doing the actual deployment, some environments 233 | first need to be prepared. A common use case would be to run DB migration 234 | scripts. 235 | * **Deployment**: Run the new configuration in your environment (pre-prod, prod). 236 | This resulting new service can either replace an old version of the same service 237 | or can run next to old versions (e.g. for B/G deployments). After doing the 238 | deployment, the new service is not necessarily exposed to actual users, i.e. 239 | the service does not serve production traffic. 240 | * **Test**: Perform all different kinds of tests like smoke tests, dark tests, 241 | security tests, integration tests, end-to-end tests, etc. 242 | * **Verification/Validation/Evaluation**: Automatically validate the performance 243 | of the new service using quality gates based on e.g. Service Level Indicators 244 | (SLIs) and Service Level Objects (SLOs). Keywords: “Quality Gates”, 245 | “Progressive Delivery” 246 | * **Approval**: Engineers manually approve the new service. 247 | * **Release**: Routes real user traffic to the new service (i.e. canary 248 | release). 249 | * **Release Verification/Validation/Evaluation**: During the rollout, check for 250 | any problems using e.g. monitoring data. 251 | * **Rollback**: This task is optionally executed if the new version does not 252 | perform well. 253 | * **Clean up**: Stop old versions of the service, which are not needed anymore. 254 | * **Continuous feedback**: At least in a devops context, there could be systems 255 | continuously monitoring the deployments running in production and providing 256 | feedback back to the product developers 257 | 258 | Overall, a collection of these tasks could direct us to the points where interfaces and libraries are needed. 259 | 260 | ### Later 261 | 262 | #### Events Standardizations 263 | 264 | ## Contributors 265 | 266 | The work with the roadmap was started by Tracy Miranda and the draft version 267 | of this document was developed on [Google Docs](https://docs.google.com/document/d/1QSzcV-rl3XwkNh4_5a_0YCugF5gprtBR-xRlzuEJ-NA/edit#). 268 | 269 | This version is the result of many discussions that took place during SIG 270 | meetings and many iterations and discussions that took place 271 | during SIG meetings. The contributors listed below made valuable contributions 272 | to the roadmap by either taking part in discussions, sharing their thoughts 273 | on the document, and/or editing the roadmap directly. 274 | 275 | Please note that the list of contributors are listed alphabetically. 276 | 277 | * Andreas Grimmer 278 | * Christie Wilson 279 | * Emil Bäckmark 280 | * Emelie Pettersson 281 | * Eric Sorenson 282 | * Fatih Degirmenci 283 | * Ignacio Pascual 284 | * Kara de la Marck 285 | * Ramin Akhbari 286 | * Tracy Miranda 287 | -------------------------------------------------------------------------------- /docs/tools-terminology.md: -------------------------------------------------------------------------------- 1 | # Tools Terminology 2 | 3 | - [Introduction](#introduction) 4 | - [Terminology Used by CI/CD Tools and Technologies](#terminology-used-by-cicd-tools-and-technologies) 5 | - [ArgoCD](#argocd) 6 | - [CDEvents](#cdevents) 7 | - [CircleCI](#circleci) 8 | - [Codefresh](#codefresh) 9 | - [Eiffel](#eiffel) 10 | - [GitHub Actions](#github-actions) 11 | - [GitLab CI/CD](#gitlab-cicd) 12 | - [Harness](#harness) 13 | - [Jenkins](#jenkins) 14 | - [Jenkins X](#jenkins-x) 15 | - [Keptn](#keptn) 16 | - [Screwdriver](#screwdriver) 17 | - [Spinnaker](#spinnaker) 18 | - [Tekton](#tekton) 19 | - [Woodpecker](#woodpecker) 20 | - [Zuul](#zuul) 21 | - [Terminology Used by SCM Tools and Technologies](#terminology-used-by-scm-tools-and-technologies) 22 | - [Gerrit](#gerrit) 23 | - [GitHub](#github) 24 | - [GitLab](#gitlab) 25 | - [Mapping of Terms](#mapping-of-terms) 26 | - [CI/CD Tools and Technologies](#cicd-tools-and-technologies) 27 | - [SCM Tools and Technologies](#scm-tools-and-technologies) 28 | - [References](#references) 29 | 30 | ## Introduction 31 | 32 | There are many ways to greet someone and as humans if we do not understand the 33 | word being used we have the ability to observe body language, process tone, 34 | and even touch. These many different natural inputs allow us as humans to 35 | establish shared vocabulary upon which we have been able to build successful 36 | components relevant to our way of living and social norms of interacting. 37 | 38 | Unfortunately for machines, this process is not so easy as we humans have to 39 | decide if we want to establish norms which we often surface when talking about 40 | machine interactions as protocols and best practices or requirements. 41 | 42 | Continuous Integration (CI) and Continuous Delivery (CD) practitioners have 43 | many tools at their disposal but it is often the case that what we call a 44 | pipeline in today’s tool of choice is not called the same thing in the tool we 45 | use tomorrow. Again, we can within our sphere of influence and interaction 46 | adjust for these nuances but machines talking to one another do not have that 47 | same luxury necessarily. 48 | 49 | The purpose of this document is to collect the basic terms used by CI/CD tools 50 | and technologies in order to work on establishing a shared vocabulary for us 51 | humans to communicate and collaborate better. 52 | 53 | If you are looking for the terminology used for common pipeline stages and steps, 54 | please consult [the pipelines terminology](./pipelines-terminology.md) document 55 | which is located next to this document. 56 | 57 | ## Terminology Used by CI/CD Tools and Technologies 58 | 59 | This section contains list of some key terms used by various CI/CD tools and 60 | technologies. 61 | 62 | ### ArgoCD 63 | 64 | [ArgoCD](https://argoproj.github.io/argo-cd/) is a declarative, GitOps continuous delivery tool for Kubernetes. 65 | 66 | Some of the core ArgoCD concept are listed below: [[16]] 67 | 68 | - **Application**: A group of Kubernetes resources as defined by a manifest. This is a Custom Resource Definition (CRD). 69 | - **Application controller** [[19]]: Kubernetes controller which continuously monitors running applications and compares live vs. desired state. 70 | - **Application source type**: Which tool is used to build the application. 71 | - **Target state**: The desired state of an application, as represented by files in a Git repository. 72 | - **Live state**: The live state of that application. What pods etc are deployed. 73 | - **Sync status**: Whether or not the live state matches the target state. Is the deployed application the same as Git says it should be? 74 | - **Sync**: The process of making an application move to its target state. E.g. by applying changes to a Kubernetes cluster. 75 | - **Sync operation status**: Whether or not a sync succeeded. 76 | - **Refresh**: Compare the latest code in Git with the live state. Figure out what is different. 77 | - **Health**: The health of the application, is it running correctly? Can it serve requests? 78 | - **Tool**: A tool to create manifests from a directory of files. E.g. Kustomize or Ksonnet. See Application Source Type. 79 | - **Configuration management tool**: See tool. 80 | - **Configuration management plugin**: A custom tool. 81 | - **Project** [[17]]: A logical grouping of applications. They enable control over deployment permissions based on source, target and kind, among other criteria. 82 | - **Sync phases** [[18]]: Pre-sync, sync and post-sync allow for controlled orchestrated execution of sync operations. 83 | - **Sync waves**: Within any one sync phase, an additional control of sequential execution is accomplished using waves, to ensure certain resources are healthy before subsequent resources are synced. 84 | 85 | ### CDEvents 86 | 87 | [CDEvents](https://cdevents.dev) is a common specification for Continuous 88 | Delivery events, enabling interoperability in the complete software production 89 | ecosystem. 90 | 91 | ***Note:*** *The CDEvents vocabulary is under early development and might thus 92 | change quite a lot before reaching a stable set of terms. That work can be 93 | followed on the [CDEvents Documentation page](https://cdevents.dev/docs/).* 94 | 95 | Some of the core CDEvents terms are listed below. [[21]] 96 | 97 | - **Event**: An Event is a data record expressing an occurrence, within the 98 | software production ecosystem, and its context. 99 | - **Task**: A Task could for example perform a build, run some tests or publish 100 | an artifact. 101 | - **Pipeline**: A Pipeline is composed by a set of Tasks to be performed. 102 | - **TaskRun**: An instantiation of a Task. 103 | - **PipelineRun**: An instantiation of a Pipeline. 104 | - **Change**: A Change identifies a proposed set of changes to the content of a 105 | source code repository. 106 | - **Artifact**: An Artifact is usually produced as output of a build process. 107 | - **Environment**: An Environment is a platform which may run a service. 108 | - **Service**: A service can represent for example a binary that is running, a 109 | daemon, an application or a docker container. 110 | 111 | ### CircleCI 112 | 113 | [CircleCI](https://circleci.com) allows teams to rapidly build quality 114 | projects, at scale. 115 | 116 | Some of the core CircleCI terms are listed below. [[1]] 117 | 118 | - **Step**: A step is a collection of executable commands. 119 | - **Job**: A job is a collection of steps. 120 | - **Workflow**: A Workflow is a set of rules for defining a collection of 121 | jobs and their run order. (used interchangeably with pipeline) 122 | - **Pipeline**: A pipeline is an object that you may configure and run on 123 | the CircleCI platform. 124 | - **Executor**: Defines the underlying technology to run a job. 125 | 126 | ### Codefresh 127 | 128 | [Codefresh](https://codefresh.io/) is a modern CI/CD platform with native Docker, Kubernetes and Helm support that allows you to easily build, integrate, and deploy your product. 129 | 130 | Some of the core Codefresh concepts are listed below: [[20]] 131 | 132 | - **Projects**: The top-level concept in Codefresh. You can create projects to group pipelines that are related. In most cases a single project will be a single application (that itself contains many micro-services). 133 | - **Pipelines**: Each project can have multiple pipelines. Pipelines that belong to a single project are easily managed all together. 134 | - **Pipeline Steps**: Each pipeline has a definition that defines the pipeline steps that are executed each time this pipeline is triggered. The definition of a pipeline is described in a special codefresh.yml file. 135 | - **Triggers**: Each pipeline can have zero, one, or more triggers. Triggers are the linking medium between a pipeline and a git repository. Codefresh supports several kinds of triggers such as Git, Cron or Docker push triggers. 136 | 137 | ### Eiffel 138 | 139 | [Eiffel](https://eiffel-community.github.io/) is a technology agnostic CI/CD event protocol. The events and their parameters are generic enough to cover any kind of CI/CD engine/framework and SCMs. 140 | 141 | Some of the terms used in Eiffel events are listed below. [[14]] 142 | 143 | - **Activity**: An activity is any kind of action in a CI/CD system, normally triggered by an operation done in an SCM system or by a previous activity. Activities are hierarchical. Activities could be whole pipelines, pipeline steps or any level of pipeline sub steps. 144 | - **Event**: An Eiffel event is a broadcast notification telling any consumer about an event occurring in the CI/CD pipeline. 145 | - **Artifact**: Artifacts are items or software packages generated in a CI/CD pipeline, for example a built binary or a Docker image. An artifact should be possible to identify using a purl ([package URL](https://github.com/package-url/purl-spec)). An artifact is often the subject of a test executed or a delivery performed within a CI/CD pipeline. 146 | - **Environment**: An Eiffel environment defines the environment in which an activity is executed. Could be for example a host, node, service name/uri, a Docker image or some other kind of machine configuration definition. 147 | - **Source Change**: A source change is the unit of a review. It results in a single commit when merged to the Git repository. 148 | - **Submit**: A submit is the action of merging a source change to its intended target branch. 149 | - *Pipeline*: A pipeline is not a term defined by Eiffel, but it is used in the Eiffel protocol documentation when explaining how Eiffel events can be combined to form a chain of activities often triggered by a source change being created or submitted. 150 | - *Step*: A step is not a term defined by Eiffel, but it is used in the Eiffel protocol documentation to exemplify activities executed in a pipeline. 151 | 152 | ### GitHub Actions 153 | 154 | [GitHub Actions](https://help.github.com/en/actions) enables the creation of 155 | custom software development life cycle (SDLC) workflows using GitHub 156 | repositories. 157 | 158 | Some of the core GitHub Actions terms are listed below. [[2]] 159 | 160 | - **Action**: Individual tasks that you combine as steps to create a job. 161 | Actions are the smallest portable building block of a workflow. 162 | - **Step**: A step is a set of tasks performed by a job. 163 | - **Job**: A defined task made up of steps. 164 | - **Workflow**: Workflows are made up of one or more jobs and can be scheduled 165 | or activated by an event. 166 | - **Workflow run**: An instance of your workflow that runs when the pre 167 | configured event occurs. 168 | - **Event**: A specific activity that triggers a workflow run. 169 | - **Runner**: Any machine with the GitHub Actions runner application installed. 170 | 171 | ### GitLab CI/CD 172 | 173 | [GitLab CI/CD](https://docs.gitlab.com/ee/ci/introduction/) is a part of the 174 | GitLab DevOps platform that allows users to apply all the continuous methods 175 | (Continuous Integration, Delivery, and Deployment) to their software with 176 | no third-party application or integration needed. 177 | 178 | Some of the core GitLab CI/CD terms are listed below. [[3]] 179 | 180 | - **Job**: Instructions that a runner has to execute. 181 | - **Stage**: Elements to group and run jobs in certain way - jobs in same 182 | stage are run in parallel and jobs in next stage run after the jobs from the 183 | previous stage completed successfully. 184 | - **Pipeline**: A collection of jobs split into different stages. 185 | - **Runner**: An agent or server that executes each job individually that can 186 | spin up or down as needed. 187 | - **Trigger**: Trigger allows you to define downstream pipeline trigger. 188 | 189 | ### Harness 190 | 191 | [Harness](https://harness.io/) is a modern software delivery platform which enables developers to fully automate and govern the build and deploy processes, with faster feedback loops thereby enhancing the developer experience. 192 | 193 | Some of the core Harness terms are listed below. [[15]] 194 | 195 | - **Manager**: Where your deployment configurations are stored and pipelines are managed. 196 | Either available as a SaaS or on-prem. 197 | - **Delegate**: Worker node that is installed in your environment which performs Continuous 198 | Delivery tasks by connecting to your infrastructure. 199 | - **Application**: How a deployment project is organized. 200 | - **Service**: Represent your microservices and applications. 201 | - **Environment**: Represent your deployment infrastructure e.g Dev, QA, Prod. 202 | - **Workflow**: Model how your application is deployed, verified, and rolled back in steps. 203 | - **Pipeline**: Model your entire release process in stages. 204 | - **Infrastructure Provisioner**: Infrastructure as code orchestration. 205 | - **Triggers**: To automate deployments using a variety of conditions, such as Git events, new artifacts, schedules, and the success of other Pipelines. 206 | 207 | ### Jenkins 208 | 209 | [Jenkins](https://jenkins.io/) is an open source automation server which 210 | enables developers around the world to reliably build, test, and deploy their 211 | software. 212 | 213 | Some of the core Jenkins terms are listed below. [[4]] 214 | 215 | - **Job**: A user-configured description of work which Jenkins should 216 | perform, such as building a piece of software, etc. 217 | - **Project**: A deprecated term, synonymous with Job. 218 | - **Stage**: Stage is part of Pipeline, and used for defining a conceptually 219 | distinct subset of the entire Pipeline 220 | - **Pipeline**: A user-defined model of a continuous delivery pipeline (see [Jenkins Pipeline](https://jenkins.io/doc/book/pipeline/)). 221 | - **Agent**: A machine or a container which is connected to the Jenkins master and capable of executing Pipelines or Jobs. 222 | Both the Master and Agents are considered to be Nodes. 223 | - **Node**: A machine or a container which is part of the Jenkins environment and capable of executing Pipelines or Jobs. 224 | Both the Master and Agents are considered to be Nodes. 225 | - **Trigger**: A criteria for triggering a new Pipeline run or a Job. 226 | 227 | ### Jenkins X 228 | 229 | [Jenkins X](https://jenkins-x.io/) provides pipeline automation, built-in 230 | GitOps, and preview environments to help teams collaborate and accelerate 231 | their software delivery at any scale. 232 | 233 | Some of the core Jenkins X terms are listed below. [[5]] 234 | 235 | - **Step**: Basic building block to execute one or more commands. 236 | - **Stage**: Collection of steps and the required configuration. 237 | - **Pipeline**: Collection of one or more stages to run. 238 | - **Agent**: Container image or Jenkins agent to schedule pipelines on. 239 | - **Trigger**: A pipeline trigger defines when to automatically run a pipeline. 240 | 241 | ### Keptn 242 | 243 | [Keptn](https://keptn.sh/) is an event-based control plane for continuous delivery and automated operations for cloud-native applications. 244 | 245 | Some of the core Keptn terms are listed below. [[6]] 246 | 247 | - **Shipyard:** A shipyard is the declarative means to divide an environment into stages and to specify workflows for each stage. 248 | - **Workflow**: A workflow declares a set of tasks for implementing a delivery or operations process. A workflow is triggered by an external event, i.e., by a *domain event*. Examples for domain events would be the availablity of a new artifact that should be deployed (i.e., a `new-artifact` event) or the occurence of a problem (i.e., a `problem` event). 249 | - **Task**: A task is the smallest executable unit in a workflow. A task is triggered by an event. 250 | - **Event**: An event triggers a task and contains relevant data for the respective task. 251 | - **Keptn-service:** A Keptn-service is the unit executing a task. It can be responsible for executing one or many tasks and is triggered by an event of a task. 252 | 253 | ### Screwdriver 254 | 255 | [Screwdriver](https://screwdriver.cd) is an open source build platform designed 256 | for Continuous Delivery. 257 | 258 | Some of the core Screwdriver terms are listed below. [[7]] 259 | 260 | - **Step**: List of commands to execute. 261 | - **Job**: Collection of the steps to run. 262 | - **Workflow**: Collection and order of jobs to run. 263 | - **Pipeline**: Used interchangeably with workflow. (*citation needed*) 264 | - **Trigger**: A pipeline trigger defines when to automatically run a pipeline 265 | or job. (*citation needed*) 266 | 267 | ### Spinnaker 268 | 269 | [Spinnaker](https://www.spinnaker.io/) is an open source, multi-cloud continuous 270 | delivery platform for releasing software changes with high velocity and 271 | confidence. 272 | 273 | Some of the core Spinnaker terms are listed below. [[8]] 274 | 275 | - **Task**: An atomic function to perform. 276 | - **Stage**: A collection of sequential Tasks and composed Stages that describe 277 | a higher-level action the Pipeline will perform either linearly or in parallel. 278 | - **Pipeline**: The pipeline is the key deployment management construct in 279 | Spinnaker. It consists of a sequence of actions, known as stages. 280 | - **Pipeline Template**: A parameterized pipeline, minus the pipeline 281 | configuration found on a pipeline instance. This template helps developers 282 | create pipelines that follow a pattern that you establish. 283 | - **Pipeline configuration**: The same as the configuration for a pipeline 284 | not created from a template, plus variable bindings and a reference to the 285 | template. 286 | - **Cluster**: Logical groupings of Server Groups in Spinnaker. 287 | - **Provider**: A Cloud Provider is an interface to a set of virtual resources 288 | that Spinnaker has control over. 289 | - **Trigger**: A pipeline trigger defines when to automatically run a pipeline. 290 | 291 | ### Tekton 292 | 293 | [The Tekton Pipelines](https://github.com/tektoncd/pipeline) project provides 294 | k8s-style resources for declaring CI/CD-style pipelines. 295 | 296 | Some of the core Tekton terms are listed below. [[9]] 297 | 298 | - **Step**: a specific function to perform. 299 | - **Task**: is a collection of sequential steps you would want to run as part 300 | of your continuous integration flow. A task will run inside a pod on your cluster. 301 | - **Pipeline**: stateless, reusable, parameterized collection of tasks. Tasks are 302 | linked together in a Pipeline, which describes the end-to-end deployment for an application. 303 | - **PipelineRun**: an instantiation of a Pipeline definition, filling in the 304 | Pipeline's parameters with concrete values 305 | - **Trigger**: Triggers is a Kubernetes Custom Resource Defintion (CRD) controller 306 | that allows you to extract information from event payloads (a "trigger") to create Kubernetes resources. 307 | 308 | ### Woodpecker 309 | 310 | [Woodpecker](https://woodpecker-ci.org/) is an open source, simple CI/CD engine with great extensibility. 311 | 312 | Some of the core Woodpecker terms are listed below. [[22]] 313 | 314 | - **Pipeline**: Triggered by events like webhooks, crons or manual events. It contains one or more workflows. 315 | - **Workflow**: Represents a sequential list of steps which are executed as a task by an agent. The results of the workflow reports the result back to SCM Tools. 316 | - **Workspace**: Contains the shared state of a workflow. 317 | - **Step**: Are commands to be executed in a sequence within a specific environment (container image) declared by it. 318 | - **Plugin**: Are steps that have pre declared commands witch are just configured by settings. 319 | - **Agent**: Do have a backend engine, default is docker. They execute workflows. 320 | - **Server**: Interacts with the SCM Tools and orchestrate tasks to agents. 321 | 322 | ### Zuul 323 | 324 | [Zuul](https://zuul-ci.org/) is a program that drives continuous integration, 325 | delivery, and deployment systems with a focus on project gating and 326 | interrelated projects. 327 | 328 | Some of the core Zuul terms are listed below. [[10]] 329 | 330 | - **Job**: A job is a unit of work performed by Zuul on an item enqueued into 331 | a pipeline. 332 | - **Pipeline**: A pipeline describes a workflow operation in Zuul. 333 | It associates jobs for a given project with triggering and reporting events. 334 | to one or more projects. 335 | - **Trigger**: Descriptions of events which should cause something to be 336 | enqueued into a pipeline. 337 | - **Node**: Virtual or static machines where the jobs are scheduled on. 338 | - **Executor**: Executors are responsible for running jobs. 339 | 340 | ## Terminology Used by SCM Tools and Technologies 341 | 342 | This section contains list of some key terms of various SCM tools and 343 | technologies. 344 | 345 | ### Gerrit 346 | 347 | [Gerrit](https://www.gerritcodereview.com/) is a free, web-based team code 348 | collaboration tool. 349 | 350 | Some of the core Gerrit terms are listed below. [[11]] 351 | 352 | - **Change**: The unit of review. Results in a single commit when merged 353 | to the Git repository. Change numbers (identifiers) are unique and never 354 | change. 355 | - **Patch Set**: A revision of a Change. Each time a Change is modified, 356 | it will receive a new Patch Set. Patch Set numbering starts from 1. 357 | Technically, a Patch Set is a unique Git commit. 358 | - **Review**: Process that enables peer-review to improve the quality of 359 | code. 360 | - **Approval Category**: Name for a scope that is checked during review 361 | process. Could be given by reviewers or CI/CD processes. 362 | - **Submit**: An action that allows Gerrit to merge a Change to the Git 363 | repository. 364 | 365 | ### GitHub 366 | 367 | [GitHub](https://www.github.com) is a hosted software development version 368 | control system using Git. 369 | 370 | Some of the core GitHub terms are listed below. [[12]] 371 | 372 | - **Pull Request**: Proposed changes to a repository submitted by a user 373 | and accepted or rejected by a repository's collaborators. 374 | - **Review**: Process that enables peer-review to improve the quality of 375 | code. 376 | - **Status Check**: Status checks are external processes, such as continuous 377 | integration builds, which run for each commit you make in a repository. 378 | - **Check**: A check is a type of status check on GitHub. 379 | - **Merge**: Acceptance of a PR by the maintainers. 380 | 381 | ### GitLab 382 | 383 | [GitLab](https://www.gitlab.com) is a web-based DevOps lifecycle tool that 384 | provides a Git-repository manager providing wiki, issue-tracking and CI/CD 385 | pipeline features. 386 | 387 | Some of the core GitLab terms are listed below. [[13]] 388 | 389 | - **Merge Request**: MR is the basis of GitLab as a code collaboration and 390 | version control platform. It is as simple as the name implies: a request to 391 | merge one branch into another. 392 | - **Review**: Process that enables peer-review to improve the quality of 393 | code. 394 | - **Merge Check**: Checks to ensure MR can be merged without issues. 395 | - **Merge**: Acceptance of a MR by the maintainers. 396 | 397 | ## Mapping of Terms 398 | 399 | The Tools and Technologies listed in this document use more or less same 400 | terminology for naming things with few differences, workflow vs pipeline or 401 | runner vs node except the smaller units of work. 402 | 403 | Fields marked as *N/A* in the tables below means that the author of this 404 | document failed to identify corresponding term in the documentation of those 405 | tools and does not mean those units of work are not supported by the tools. 406 | Fields containing a question mark is the author's guess and might be incorrect. 407 | 408 | ### CI/CD Tools and Technologies 409 | 410 | The table below is an attempt to create a mapping of different terms used 411 | by CI/CD Tools and Technologies and could contain errors. The main term used 412 | while creating the table is **pipeline** since almost all the tools listed in 413 | this document use the word pipeline to describe pretty similar things. Smaller 414 | units of terms then mapped based on how they are described in relation to 415 | pipeline in corresponding documentation. 416 | 417 | | Project | | | | | | | 418 | |--------------------|-----------|------------|----------|----------|---------|------------------------| 419 | | **ArgoCD** | Sync Wave | Sync Phase | Sync | N/A | Event | Application Controller | 420 | | **CDEvents** | ? | ? | Task | Pipeline | Event | Environment | 421 | | **CircleCI** | N/A | Step | Job | Workflow | Trigger | Executor | 422 | | **Codefresh** | N/A | Step | Stage | Pipeline | Trigger | Runtime environment | 423 | | **Eiffel** | Activity | Activity | Activity | Activity | Event | Environment | 424 | | **GitHub Actions** | Action | Step | Job | Workflow | Event | Runner | 425 | | **GitLab CI/CD** | N/A | Job | Stage | Pipeline | Trigger | Runner | 426 | | **Harness** | N/A | Step | Pipeline | Workflow | Trigger | Delegate | 427 | | **Jenkins** | N/A | Job | Stage | Pipeline | Trigger | Agent/Node | 428 | | **Jenkins X** | N/A | Step | Stage | Pipeline | Trigger | Agent | 429 | | **Keptn** | N/A | N/A | Task | Workflow | Event | Keptn-service | 430 | | **Screwdriver** | N/A | Step | Job | Pipeline | Trigger | N/A | 431 | | **Spinnaker** | N/A | Task | Stage | Pipeline | Trigger | Cluster | 432 | | **Tekton** | N/A | Step | Task | Pipeline | Trigger | Resource (?) | 433 | | **Woodpecker** | N/A | Step | Workflow | Pipeline | Event | Agent | 434 | | **Zuul** | N/A | N/A | Job | Pipeline | Trigger | Node (?) | 435 | 436 | ### SCM Tools and Technologies 437 | 438 | The table below is an attempt to create a mapping of different terms used 439 | by SCM Tools and Technologies. 440 | 441 | | Project | | | | | | 442 | |--------------|---------------|-----------------|---------------|---------------|--------| 443 | | **CDEvents** | Change | (Not defined) | (Not defined) | N/A | Merge | 444 | | **Eiffel** | (Change) | Source Change | Activity | N/A | Submit | 445 | | **Gerrit** | Change | Patch Set | Review | Change State? | Submit | 446 | | **GitHub** | Pull Request | (PR commit) | Review | Check? | Merge | 447 | | **GitLab** | Merge Request | (MR commit) | Review | Merge Check? | Merge | 448 | 449 | ## References 450 | 451 | [1]: https://circleci.com/docs/2.0/glossary/ 452 | [2]: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/core-concepts-for-github-actions 453 | [3]: https://about.gitlab.com/blog/2019/07/12/guide-to-ci-cd-pipelines/ 454 | [4]: https://jenkins.io/doc/book/glossary/ 455 | [5]: https://jenkins-x.io/docs/concepts/ 456 | [6]: https://keptn.sh/docs/0.6.0/concepts/glossary/ 457 | [7]: https://docs.screwdriver.cd/user-guide/quickstart 458 | [8]: https://www.spinnaker.io/concepts/ 459 | [9]: https://github.com/tektoncd/pipeline/blob/master/docs/README.md 460 | [10]: https://zuul-ci.org/docs/zuul/discussion/concepts.html 461 | [11]: https://wiki.qt.io/Gerrit_Introduction#Terminology 462 | [12]: https://help.github.com/en/github/getting-started-with-github/github-glossary 463 | [13]: https://docs.gitlab.com/ee/user/project/merge_requests/ 464 | [14]: https://github.com/eiffel-community/eiffel/tree/master/eiffel-vocabulary 465 | [15]: https://docs.harness.io/article/4o7oqwih6h-harness-key-concepts 466 | [16]: https://argoproj.github.io/argo-cd/core_concepts/ 467 | [17]: https://argoproj.github.io/argo-cd/user-guide/projects/ 468 | [18]: https://argoproj.github.io/argo-cd/user-guide/sync-waves/ 469 | [19]: https://argoproj.github.io/argo-cd/operator-manual/architecture/ 470 | [20]: https://codefresh.io/docs/docs/configure-ci-cd-pipeline/pipelines/ 471 | [21]: https://cdevents.dev/docs 472 | [22]: https://github.com/woodpecker-ci/woodpecker/issues/745 473 | -------------------------------------------------------------------------------- /docs/vocabulary.md: -------------------------------------------------------------------------------- 1 | The SIG Interoperability recently split the document into two in order 2 | to make it easier to read. 3 | 4 | If you are looking for the terminology used by various CI/CD tools, 5 | please consult [the tools terminology](./tools-terminology.md) document 6 | which is located next to this document. 7 | 8 | If you are looking for the terminology used for common pipeline stages and steps, 9 | please consult [the pipelines terminology](./pipelines-terminology.md) document 10 | which is located next to this document. 11 | 12 | Please note that this document is kept for historical reasons and 13 | to point people who find this document via internet search to the 14 | right set of documents. 15 | -------------------------------------------------------------------------------- /docs/workstream-governance.md: -------------------------------------------------------------------------------- 1 | # Interoperability Workstreams 2 | 3 | ## Overview and Motivations 4 | 5 | Project and user representatives who take part in the Interoperability SIG are welcome to form a workstream to work on specific areas of interest in a more focused and structured way. 6 | 7 | The expectations from workstreams would vary depending on the area of focus. Workstreams could focus on collecting the state of things in a specific area from within the ecosystem and contribute that to the domain, or come up with a proposal to address some of the needs in a more structured way in order to socialize their ideas further and increase the awareness. 8 | 9 | Workstreams should, at a regular cadence, share their progress with the rest of the SIG. Workstreams could liase with the Interoperability SIG to present ideas per area on CDF TOC level in order to gather feedback. 10 | 11 | ## Lifecycle 12 | 13 | Working groups are temporary in nature. They are formed to focus on specific goals and can be disbanded after reaching their goals. Upon formation, leads for the working group are choosen by the working group. When leads step down, they can be replaced by [lazy concensus](https://wiki.openoffice.org/wiki/Documentation/FAQ/ProjectLevel/CommunityQuestions/What_is_%22Lazy_Consensus%22%3F). However, working groups can also be disbanded if there is no longer a lead for the working group (within an 8 week grace period). 14 | 15 | ## Proposing a new Workstream 16 | 17 | We welcome proposals for new workstreams. 🎉 18 | 19 | Proposals for new workstreams can be made via a [PR](https://github.com/cdfoundation/sig-interoperability/pulls) on the Interoperability SIG repo, for discussion and feedback. 20 | 21 | Please create a directory in the [workstreams directory](../workstreams/) with a README providing information about the workstream's focus, goals, membership, and meeting logistics. 22 | 23 | Add your proposal, and a link to your PR, to our [meeting notes](https://hackmd.io/@cdf-sig-interoperability/ry3TTB5DL) as an agenda item to discuss at the next SIG meeting. Discussion during the SIG is a great way to gather further feedback and support and attract additional collaborators. 24 | 25 | 26 | 27 | ## Current Workstreams 28 | 29 | Current workstreams can be found in the [workstreams directory](../workstreams/). 30 | 31 | ## Archived Workstreams 32 | 33 | Archived workstreams can be found in the [archived workstreams directory](../workstreams/archived/). 34 | 35 | * [Events in CICD](../workstreams/archived/events_in_cicd/README.md) 36 | -------------------------------------------------------------------------------- /workstreams/archived/events_in_cicd/README.md: -------------------------------------------------------------------------------- 1 | # Events in CI/CD Readme 2 | 3 | ***Note! This workstream is suggested to become a SIG through [this PR](https://github.com/cdfoundation/toc/pull/91). If that PR is accepted the information here will be moved to its own repository under [CD Foundation](https://github.com/cdfoundation). References to the new repo will be added here once that is set.*** 4 | 5 | This is a workstream within the CDF SIG Interoperability. 6 | 7 | The forming of this workstream was suggested on a [recent SIG Interoperability meeting]( https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings.md#may-28-2020) and its first meeting was held on June 8th. 8 | 9 | ## Scope 10 | Discuss all about what events should be used for in a CI/CD process 11 | 12 | ## Mission 13 | Standardize events to be used in a CI/CD process 14 | 15 | ## What is an event? 16 | We currently stick with the [definition used by CloudEvents](https://github.com/cloudevents/spec/blob/v1.0/spec.md#terminology): 17 | An *event* is a data record expressing an *occurrence* and its context, where *occurrence* is the capture of a statement of fact during the operation of a software system. 18 | 19 | ## Members 20 | Current members: 21 | * Ravi Lachhman, Harness 22 | * Andreas Grimmer, Dynatrace 23 | * Emil Bäckmark, Ericsson 24 | * Ramin Akhbari, eBay 25 | * Mattias Linnér, Ericsson 26 | * Andrea Frittoli, IBM 27 | 28 | Membership to this workstream is open to public and self-declared. 29 | 30 | New members are advised to: 31 | * Join the [#events-in-cicd channel on CDF Slack](https://cdeliveryfdn.slack.com/archives/C0151BTKEJX) and introduce yourself. 32 | * Update [this HackMD document](https://hackmd.io/AnVkdMb3QEeVQXKfIj4tNQ) with your name and ping Emil Bäckmark on Slack to push the update to Github. 33 | * Regularly join the workstream meetings. 34 | 35 | ## Communication Channels 36 | There is a [Slack channel](https://cdeliveryfdn.slack.com/archives/C0151BTKEJX) for this workstream. 37 | 38 | ## Meetings 39 | Events in CI/CD workstream meets regularly to discuss a propsal on a common events protocol for CI/CD systems. For details on the agenda, meeting time, and minutes of meeting, please check [here](https://github.com/cdfoundation/sig-interoperability/blob/master/workstreams/events_in_cicd/meetings.md). 40 | -------------------------------------------------------------------------------- /workstreams/archived/events_in_cicd/charter.md: -------------------------------------------------------------------------------- 1 | # Charter for Events in CI/CD 2 | 3 | ## Introduction 4 | Today’s CI/CD systems do not talk to each other in a standardized way. This leads to problems related to interoperability, notification of failure issues, and poor automation. 5 | 6 | This group is looking at how events can help to create CI/CD systems with a decoupled architecture that is easy to scale and makes it resilient to failures. Using events could also increase automation when connecting workflows from different systems to each other, and as a result empowering tracing/visualizing/auditing of the connected workflows through these events. 7 | 8 | ## Purpose 9 | The group will focus on the use of events to provide interoperability through topics like: 10 | - When are events suited? For triggers, audits, monitoring, management 11 | - Common guidelines for at-least-once, at-most-once, exactly once, ordering… When to apply what strategy? 12 | - Best practices for event-driven CI/CD systems 13 | - Events to be used by tools for orchestration/workflows 14 | - Pipeline to pipeline communication via events 15 | - Tracing/auditing/graphing/visualizing of the entire process, e.g., through events. What truly occurs? 16 | - Metrics, e.g., how many versions have been deployed, how many PRs (Pull Requests) have been raised, how many events have been issued? 17 | - How are events related and how are they ordered (links vs trace context)? 18 | 19 | ## Outcome 20 | The group is working on a standardized event protocol that caters for technology agnostic machine-to-machine communication in CI/CD systems. This specification will be published, reviewed and agreed upon between relevant Linux Foundation projects/members. 21 | 22 | The group aims to provide reference implementations such as event listeners and event senders on top of CloudEvents. 23 | 24 | ## Relations to other groups 25 | ### CDF SIG Interoperability 26 | To be defined 27 | ### CDF Metadata Workstream 28 | To be defined 29 | ### CloudEvents 30 | To be defined 31 | ### CNCF CI/CD Projects 32 | To be defined 33 | 34 | -------------------------------------------------------------------------------- /workstreams/archived/events_in_cicd/meetings.md: -------------------------------------------------------------------------------- 1 | # Events in CICD Workstream Meeting Notes 2 | 3 | [![hackmd-github-sync-badge](https://hackmd.io/QijjoIAiSeCNhaLpXhr05w/badge)](https://hackmd.io/QijjoIAiSeCNhaLpXhr05w) 4 | 5 | 6 | This workstream meet every second Monday at 16.00 UTC (See your timezone [here](https://time.is/1600_in_UTC)). The meeting can be accessed through this zoom link: https://zoom.us/j/97660712600?pwd=Z3BqYTE5YzNsbEhmck16cjdZNEFIUT09 7 | 8 | The forming of this workstream was suggested on a [recent SIG Interoperability meeting]( https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings.md#may-28-2020) and its first meeting was held on June 8th. 9 | 10 | Meeting notes for the workstream are managed on HackMD [here](https://hackmd.io/QijjoIAiSeCNhaLpXhr05w), and published to GitHub [here](https://github.com/cdfoundation/sig-interoperability/blob/master/workstreams/events_in_cicd/meetings.md). 11 | 12 | ## Meeting March 1st 13 | Meeeting time in your timezone [here](https://time.is/1600_1_March_2021_in_UTC). You're welcome to join! 14 | 15 | Participants: 16 | - Emil Bäckmark, Ericsson 17 | - Erik Sternerson, doWhile 18 | - Ravi Lachhman, Harness 19 | - Mattias Linnér, Ericsson 20 | - Steve Taylor, DeployHub 21 | - Tracy Ragan, DeployHub 22 | - Kara de la Marck, CloudBees 23 | - Andrea Frittoli, IBM 24 | - Mauricio Salatino, Camunda / LearnK8s 25 | - \ 26 | 27 | ### Agenda and Notes 28 | - Tracy M: Promoting the SIG 29 | - Roxanne is here to prepare for the announcement 30 | - https://docs.google.com/document/d/1-dITtHInAnwpdoYo2_idQP2IG1CvNI6whqSzE8VckZk/edit# 31 | - We will provide some quotes to that. Exampel from Jenkins https://cd.foundation/announcement/2020/08/04/cd-foundation-announces-jenkins-graduation/ 32 | - Podcast 33 | - Ravi, Mauricio and Andrea will join 34 | - Postcast template: https://docs.google.com/document/d/1K-taXA4k5wc82tFQMVXvMDJArCANT2D4nneSmeVldzs/edit 35 | - Blog posts 36 | - Can be sent at any time to Roxanne, and not only about the Events SIG 37 | - Daylight Savings Time 38 | - US starts on March 14th already: https://www.timeanddate.com/time/change/usa/new-york 39 | - Europe two weeks later: https://www.timeanddate.com/time/change/sweden/stockholm 40 | - What is [your time](https://time.is/1600_15_March_2021_in_UTC) on Monday in two weeks? Ok to keep the current time slot (4pm UTC)? 41 | - Decision: We keep the same time UTC next occasion as well 42 | - We're a SIG! 43 | - Tracy M has asked us (during last SIG Interop meeting) to provide quotes for a CDF announcement of SIG Events - deadline March 1st. Example of topics: 44 | - About the problem space 45 | - The connection to CloudEvents 46 | - How it as been a spinoff from SIG Interoperability (Kara/Fatih) 47 | - New repo created for SIG Events 48 | - https://github.com/cdfoundation/sig-events/ 49 | - Everyone can create a PR to that repo to be automatically included as contributors to the repo, and can then be added to the team 50 | - Update the [sig interoperability page](https://github.com/cdfoundation/sig-interoperability/README.md) in the cdfoundation repo 51 | - (Andrea) Make a PR to move documents and update links 52 | - Move our stuff from https://github.com/cdfoundation/sig-interoperability/tree/master/workstreams/events_in_cicd 53 | - (Andrea) Make a PR to move documents into the new repo 54 | - Add the mailing list to the communication channel once allocated 55 | - Tracy M will create the maillist for us sig-events@lists.cd.foundation subscribe via https://lists.cd.foundation/g/sig-events 56 | - Andrea will add info about it to our readmes 57 | - HackMD document updates (title, new hackmd team, github sync). Create new team in Hackmd 58 | - Emil to create a new hackmd team and connect its docs to the new SIG Events github 59 | - Emil put a note in the old document saying this is now archived and is continued in the new document 60 | - Slack channel renamed to sig-events, and change its description. 61 | - Tracy M will reach out to Gale to rename our channel to sig-events 62 | - Emil updates the description in the Slack channel 63 | - Andrea to update info in the README 64 | - Write a blog post on the CDF blog 65 | - Mauricio to start it 66 | - A follow up on the announcement 67 | - Mentioning specific initiatives if applicable 68 | - Use cases 69 | - CDF Podcast 70 | - See above 71 | - Setup GitHub repo 72 | - Created sig-events team, sig-events-admin team 73 | - Add chairs as admins, everyone else as maintainer 74 | - https://github.com/cdfoundation/sig-events/ 75 | - Initial Vocabulary Proposal 76 | - First vocabulary meeting brief 77 | - Initial Vocabulary Proposal PR https://github.com/cdfoundation/sig-interoperability/pull/64/files 78 | - Proposed inital workflow for working on the vocabulary 79 | - Break the PR into smaller chunks to be able to merge sooner. Mauricio will fix. 80 | - PR comments for discussions directly related to the PR 81 | - GitHub Discussions for "more involved" topics, consider announcing on Slack when there is a new discussion you want some attention on. 82 | - Who can enable GitHub Discussions for our repo? 83 | 84 | 85 | ## Meeting February 15th 86 | Meeeting time in your timezone [here](https://time.is/1600_15_February_2021_in_UTC). You're welcome to join! 87 | 88 | Participants: 89 | - Emil Bäckmark - Ericsson 90 | - Mauricio Salatino - Camunda / LearnK8s 91 | - Mattias Linnér - Ericsson 92 | - Andreas Grimmer, Keptn 93 | - Erik Sternerson - doWhile 94 | - Andrea Frittoli - IBM 95 | - Tracy Ragan - DeployHub 96 | - Aleksandra Fedorova - Red Hat 97 | 98 | ### Agenda and Notes 99 | 100 | - APs 101 | - (salaboy) Setting a time in the calendar for Vocabulary discussion and progress 102 | - Mauricio will set up a separate meeting to start that discussion. Proposal: same time, different day. AP salaboy 103 | - Categories of events added to our vocabulary document - https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA 104 | - Becoming a SIG 105 | - Waiting for votes in TOC 106 | - (afrittoli) Licenses for content produced by the group / SIG (see https://cdeliveryfdn.slack.com/archives/C0151BTKEJX/p1612211728022200) 107 | - Emil reached out to Dan, waiting for reply. Emil pings Dan again :) 108 | - Input to this discussion: https://github.com/CommunitySpecification/1.0 109 | - [Enterprise-Scale CI](https://github.com/erkist/sig-interoperability/tree/erkist-esci/workstreams/events_in_cicd/input/enterprise-scale-ci) concepts - Erik Sternerson 110 | - Complementing info from Aleksandra on RedHat (Fedora): https://quantum-integration.org/posts/ci-system-vs-ci-pipeline.html 111 | - Also worth relating to the SIG Interoperability vocabulary document (Rosetta Stone): https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md 112 | - Upcoming Presentations 113 | - [Events Vocabulary](https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA?view) 114 | - [CD Flow](https://github.com/salaboy/cd-flow/) - date to be decided 115 | 116 | ### APs 117 | - ~~Andrea: Reach out on the cloudevents Slack channel - https://cloud-native.slack.com/archives/C9DB5ABAA/p1612448038043100~~ 118 | - ~~All: We should define buckets of terms to define, e.g. artifacts, activities, deployments etc and continue diving into those to propose vocabulary for them - Let's discuss how to proceed on that on Slack~~ 119 | - Mauricio (Salaboy) to set up a meeting series for vocabulary discussions 120 | 121 | 122 | ## Meeting February 1st 123 | Meeeting time in your timezone [here](https://time.is/1600_1_February_2021_in_UTC). You're welcome to join! 124 | 125 | Participants: 126 | - Emil Bäckmark, Ericsson 127 | - Erik Sternerson, doWhile 128 | - Mattias Linnér, Ericsson 129 | - Andrea Frittoli, IBM 130 | - Mauricio Salatino, Camunda / LearnK8s 131 | - Andreas Grimmer, Keptn 132 | - Tracy Ragan, DeployHub / Ortelius 133 | - Gareth Evans, CloudBees 134 | 135 | ### Agenda and Notes 136 | 137 | #### Upcoming Conferences 138 | - [FOSDEM 2021](https://fosdem.org/2021/) - February 7th - 8th 139 | - [Istio-CON](https://sessionize.com/istiocon-2021/) - Feb 22 - 25, 2021 140 | - [Devops Online Summit](https://devopsonlinesummit.com/) - April 26th – 30th 141 | - [CFP](https://devopsonlinesummit.com/the-tremendous-devops-online-summit-2021-tracks-have-just-arrived/) closes on February 7th 142 | - Focus topics: Trends in CI/CD and landscape for CI/CD 143 | - [cdCon 2021](https://events.linuxfoundation.org/cdcon/) - June 23rd - 24th 144 | - [CFP](https://events.linuxfoundation.org/cdcon/program/cfp/) closes March 5th (Early Bird closes February 19th) 145 | - TR: A panel proposal would be good. They are often well attended. 146 | - FYI (partly relevant) [Scaling Continuous Delivery](https://continuousdeliveryatscale.splashthat.com/) February 2nd, Ravi and Andrea will be presenting 147 | 148 | #### Becoming a SIG 149 | - [Draft PR created](https://github.com/cdfoundation/toc/pull/91) 150 | - Will probably be discussed on tomorrow's TOC meeting: https://docs.google.com/document/d/1uBHar55fTInWF9Li4t0lyG3tTC8BRLU0FfBfsgk_Jrs/edit?ts=5c9580be# 151 | - Meeting cadence needs to be in sync with Best Practices SIG 152 | - Events SIG meet every 1st and 3rd Monday of the month 153 | - Best Practices SIG should meet every 2nd and 4th Monday of the month. @Mauricio to bring that to Best Practices SIG. 154 | - Follow-up to be done once the SIG proposal is accepted 155 | - Update the [sig interoperability page](https://github.com/cdfoundation/sig-interoperability/README.md) in the cdfoundation repo 156 | - Move our stuff from https://github.com/cdfoundation/sig-interoperability/tree/master/workstreams/events_in_cicd 157 | - Add the mailing list to the communication channel once allocated 158 | - HackMD document updates (title, new hackmd team, github sync). Create new team in Hackmd 159 | - Slack channel renamed to sig-events, and change its description. 160 | - Write a blog post on the CDF blog. (Mauricio to start it) 161 | - CDF Podcast 162 | - Setup GitHub repo 163 | - Create/ask to create sig-events team, sig-events-admin team 164 | - Add chairs as admins, everyone else as maintainer 165 | 166 | #### Contribute to Metadata workstream 167 | - Metadata workstream is about to get started and we should provide any input we have that relates to metadata to it: [Standardized Metadata](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ) 168 | - We don't have anything to provide on 'artifacts' and 'commits' yet from our group 169 | - We should define buckets of terms to define, e.g. artifacts, activities, deployments etc and continue diving into those to propose vocabulary for them 170 | - Let's discuss how to proceed on that on Slack. AP all 171 | 172 | #### Upcoming Presentations 173 | - [CD Flow](https://github.com/salaboy/cd-flow/) - date to be decided 174 | - [Events Vocabulary](https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA?view) 175 | - [Enterprise-Scale CI](https://github.com/erkist/sig-interoperability/tree/erkist-esci/workstreams/events_in_cicd/input/enterprise-scale-ci) concepts - Erik Sternerson 176 | 177 | #### Cloud Events 178 | - Question from the Interop WG. Did we connect (or plant to) with the CloudEvents team? 179 | - Reach out on the cloudevents Slack channel - AP Andrea 180 | 181 | ### APs 182 | - Andrea: Reach out on the cloudevents Slack channel 183 | - All: We should define buckets of terms to define, e.g. artifacts, activities, deployments etc and continue diving into those to propose vocabulary for them 184 | - Let's discuss how to proceed on that on Slack 185 | 186 | ## Meeting January 18th 187 | Meeeting time in your timezone [here](https://time.is/1600_18_January_2021_in_UTC). You're welcome to join! 188 | 189 | Participants: 190 | - Andreas Grimmer, Dynatrace 191 | - Emil Bäckmark, Ericsson 192 | - Ravi Lachhman, Harness 193 | - Mattias Linnér, Ericsson 194 | - Steve Taylor, DeployHub/Ortelius 195 | - Mauricio Salatino, Camunda / LearnK8s 196 | - Erik Sternerson, doWhile 197 | - Tracy Ragan, DeployHub/Ortelius 198 | 199 | ### Agenda and Notes 200 | 201 | #### Upcoming Conferences 202 | - [FOSDEM 2021](https://fosdem.org/2021/) - February 7th - 8th 203 | - Andrea will present our workstream in the [CI/CD room](https://fosdem.org/2021/schedule/track/continuous_integration_and_continuous_deployment/) 204 | - https://afrittoli.github.io/events-in-cicd/ 205 | - [Devops Online Summit](https://devopsonlinesummit.com/) - April 26th – 30th 206 | - [CFP](https://devopsonlinesummit.com/the-tremendous-devops-online-summit-2021-tracks-have-just-arrived/) closes on February 7th 207 | - Held on Slack 208 | - Tracy Ragan will drive the CI/CD track 209 | - [cdCon 2021](https://events.linuxfoundation.org/cdcon/) - June 23rd - 24th 210 | - [CFP](https://events.linuxfoundation.org/cdcon/program/cfp/) closes March 5th (Early Bird closes February 19th) 211 | - [Istio-CON](https://sessionize.com/istiocon-2021/) - Feb 22 - 25, 2021 212 | - CFS closes today 213 | 214 | #### Becoming a SIG 215 | - Will possibly be brought up on tomorrow's TOC meeting: https://docs.google.com/document/d/1uBHar55fTInWF9Li4t0lyG3tTC8BRLU0FfBfsgk_Jrs/edit?ts=5c9580be# 216 | - [CDF Toc Invite for tomorrow](https://calendar.google.com/calendar/event?eid=N2tiaTNwamdlOW0xbnRiYzZodjgzYW10NXJfMjAyMTAxMTlUMTYwMDAwWiBsaW51eGZvdW5kYXRpb24ub3JnX21oZjBrbWdlZG42N2lobmk4cjEyOWF2cDI0QGc) 217 | - https://zoom.us/j/262239698?pwd%3DNWhQWjg2UUdKT0ZxYW1CSElwbDVodz09&sa=D&source=calendar&ust=1611503983559000&usg=AOvVaw03zXFPiKEUEw29kp-VGUje 218 | - Emil could present our workstream there 219 | - Events should be considered for all areas in the [CD Foundation Landspace](https://landscape.cd.foundation/) 220 | 221 | #### Charter 222 | [Charter document in progress](https://docs.google.com/document/d/1cuaOHmrvK20WxHxHZZuLif3CW3q1ICZ_RglJRp_IAQ0/edit?usp=sharing) 223 | - Main focus areas for the Events SIG (as written on last meetings minutes) 224 | - Defining a protocol, and documenting it 225 | - Providing how to apply the protocol in different use cases, such as monitoring, triggering activities, audits, etc 226 | - Providing a reference implementation of services/libraries showcasing the protocol 227 | 228 | #### Contribute to Metadata workstream 229 | - Metadata workstream is about to get started and we should provide any input we have that relates to metadata to it: [Standardized Metadata](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ) 230 | 231 | #### Upcoming Presentations 232 | - [CD Flow](https://github.com/salaboy/cd-flow/) - date to be decided 233 | - [Events Vocabulary](https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA?view) 234 | 235 | #### Cloud Events 236 | - Question from the Interop WG. Did we connect (or plant to) with the CloudEvents team 237 | 238 | ## Meeting December 21th 239 | Meeeting time in your timezone [here](https://time.is/1600_7_December_2020_in_UTC). You're welcome to join! 240 | 241 | Participants: 242 | - Emil Bäckmark, Ericson 243 | - Andreas Grimmer, Dynatrace 244 | - Ravi Lachhman, Harness 245 | - Andrea Frittoli, IBM 246 | - Mauricio Salatino, Camunda / LearnK8s 247 | 248 | ### Agenda and Notes 249 | 250 | #### Charter 251 | - On December 7th, we decided on working on a charter for our workstream. You can find the working document [here](https://docs.google.com/document/d/1cuaOHmrvK20WxHxHZZuLif3CW3q1ICZ_RglJRp_IAQ0/edit?usp=sharing) 252 | - Main focus areas for the Events SIG 253 | - Defining a protocol, and documenting it 254 | - Providing how to apply the protocol in different use cases, such as monitoring, triggering activities, audits, etc 255 | - Providing a reference implementation of services/libraries showcasing the protocol 256 | - We should all review and contribute to the charter before or on the next meeting 257 | 258 | #### CD-Flow 259 | Mauricio will provide a presentation on this work in a later meeting 260 | - https://github.com/salaboy/cd-flow/ 261 | 262 | #### FOSDEM CI/CD Devroom 263 | It could be nice to present the work of this group at [FOSDEM 2021](https://fosdem.org/2021/schedule/track/continuous_integration_and_continuous_deployment/). 264 | The CFP closes on Dec 27, the conference takes place (virtually) on 6, 7 Feb 2021. 265 | 266 | #### cdCon 2021 267 | We should contribute to it 268 | - cdCon will be in June 269 | - CFP (not open yet) 270 | - 'Event driven CI/CD' could be a valid topic 271 | - https://events.linuxfoundation.org/cdcon/ 272 | 273 | #### Other conferences 274 | Online DevOps online summit, on Slack. Tracy has been asked to set up a CI/CD channel for it. 275 | - https://devopsonlinesummit.com/ 276 | 277 | #### Contribute to Metadata workstream 278 | Metadata workstream is about to get started and we should provide any input we have that relates to metadata to it: [Standardized Metadata](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ) 279 | - We never discussed this agenda point at this meeting 280 | 281 | #### Next Meeting 282 | 4th of January is skipped so first meeting after new year will be 18th of January? Or do we want a meeting before the TOC meeting where the workstream becoming a SIG will be lifted? When is the next SIG Interop meeting? 283 | AP Emil: Ask Tracey/Fatih to cancel the meeting January 4th 284 | 285 | ## Meeting December 7th 286 | Meeeting time in your timezone [here](https://time.is/1600_7_December_2020_in_UTC). You're welcome to join! 287 | 288 | Participants: 289 | * Ravi Lachhman, Harness 290 | * Andreas Grimmer, Dynatrace 291 | * Emil Bäckmark, Ericsson 292 | * Steve Taylor, DeployHub 293 | * Mattias Linnér, Ericsson 294 | * Tracy Ragan, DeployHub 295 | * Andrea Frittoli, IBM 296 | 297 | ### Agenda and Notes 298 | 299 | #### Use Cases from DeployHub on this workstream 300 | - Interested in seeing some of the CDF projects move into an event driven pipeline 301 | - Ortelius keeps track of deliveries that are to be deployed and their relationships 302 | - Generate workflows on the fly 303 | - Events should be propagated saying for example 'I have completed this step' 304 | 305 | #### Events in CICD Workstream to become SIG? 306 | Let's continue the discussion on this idea brought up on last meeting. 307 | - What about the relation to SIG Interoperability? To workstream Metadata? Others? 308 | - Having a SIG means a bit more formality and also provides more visibility of the group. 309 | - To Do: Level of effort and commitments for Working Group vs SIG. 310 | - Having a SIG might attract more volunteers 311 | - A charter would be needed for a SIG. We would benefit from creating a charter, given a clear scope and direction 312 | - We should work on the charter regardless of if we become a SIG or not 313 | - AP Andreas: Set up a Google docs where we could initiate the charter work 314 | - There is a risk that this group could be slowed down due to the extra work needed 315 | - What about the metadata workstream? Should it be part of this new SIG or SIG Interop? 316 | - Sig Interop Charter: https://github.com/cdfoundation/sig-interoperability/blob/master/docs/roadmap.md#charter 317 | - We should join the TOC in January to discuss this 318 | - Tracy will ask for us to get a point on the agenda for January 19th. No preparations needed from our end. 319 | - Should SIG Interop be renamed to SIG events or should there be a separate SIG for it? 320 | - Sig Repo: https://github.com/cdfoundation/sig-interoperability 321 | 322 | #### cdCon 2021 323 | We should contribute to it 324 | - cdCon will be in June 325 | - CFP is not there yet 326 | - 'Event driven CI/CD' could be a valid topic 327 | 328 | #### Other conferences 329 | - Online DevOps online summit, on Slack. Tracy has been asked to set up a CI/CD channel for it. 330 | - https://devopsonlinesummit.com/ 331 | 332 | #### Contribute to Metadata workstream 333 | Metadata workstream is about to get started and we should provide any input we have that relates to metadata to it: [Standardized Metadata](https://hackmd.io/BYbkuR8uSlKt_w7Y4KE1OQ) 334 | - We never discussed this agenda point at this meeting 335 | 336 | #### Events Vocabulary 337 | Let's progress the vocabulary discussions 338 | - We never discussed this agenda point at this meeting 339 | 340 | #### Next Meeting 341 | Ok to meet December 21st, or should we postpone it till after xmas? What about Monday 4th of January in Epiphany week? 342 | - Decided to meet December 21st 343 | - 4th of January is skipped so first meeting after new year will be 18th of January 344 | 345 | ## Meeting November 23rd 346 | Meeeting time in your timezone [here](https://time.is/1600_23_November_2020_in_UTC). You're welcome to join! 347 | 348 | Participants: 349 | * Ravi Lachhman, Harness 350 | * Emil Bäckmark, Ericsson 351 | * Mattias Linnér, Ericsson 352 | * Cameron Motevasselani, Armory 353 | * Andrea Frittoli, IBM 354 | * Andreas Grimmer, Dynatrace 355 | * Tracy Ragan, DeployHub 356 | 357 | ### Meeting Time 358 | It was decided through a Slack discussion to move our meetings to 16.00 UTC starting from this meeting. 359 | 360 | ### Agenda 361 | 362 | #### The life of this worksteam 363 | - TR: Should this workstream be lifted to become it's own SIG? It would benefit the group and also CDF 364 | - We should collect input from the SIG Interop about this idea on Thursday. 365 | - The idea of lifting this to its own SIG should also be lifted to Dan Lorenc, to be discussed on the TOC level 366 | - Suggested scope 367 | - What would an event driven CICD 'practice' look like? 368 | - Focusing on the event protocol or a higher level? Also including events infrastructure? 369 | - Focusing on a common events listener? Or instead of a provided events listener, it could be a layer on top of an existing cloudevents library meant to listen to and parse events in certain libraries 370 | - We should get in people from Puppet as well, CircleCI, Argo, Codefresh, JFrog, Gitlab. And of course the existing: Harness, Keptn, Ortelius, Spinnaker, Weaveworks (for Flagger). And end-users like Ramin (eBay) 371 | - Focus on tools for orchestration/workflows or also release/delivery/deployment tools? 372 | - TR: Reasons for events in Ortelius 373 | - Regardless of platform used, the workflows should be able to state their progress and risk levels in a generic way. To enable 'smart CD pipelines' 374 | 375 | #### Note: 376 | - Member webinar around events next week (see CDF Calendar): 'CDF Ambassador Webinar: A Guide to Event-driven SRE-inspired DevOps', Wednesday December 2nd 377 | - https://docs.google.com/document/d/11EZfvB2FFI837nMmArnyv-wizsIJvc-4_xdgfoUXF4o/edit?ts=5fb68361#heading=h.mspta0kuuv9j 378 | 379 | #### Is the discussion frequency good as it is or should we increase it, through using the Slack channel or comments in the HackMD document? 380 | - Discussion to be continued on this topic when/if the workstream is lifted to it's own SIG 381 | 382 | #### Metadata group 383 | - What about [the Standardized Metadata discussion](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings.md#agenda-and-notes-1) that was brought up on last SIG meeting? How should it relate to our work in this workstream? 384 | - If events in CICD will become a SIG then maybe the metadata group should be part of it 385 | 386 | ### Community Specification 387 | - [Community Specification](https://github.com/CommunitySpecification/1.0), would it be interesting for us to use? 388 | - It's about getting a head start in defining a new specification. Taking care of legal aspects etc. 389 | - It could be cloned or linked to from a new specification that we create for events 390 | - What about Cloudevents? Do they use this? Why? Why not? 391 | - It might already be covered within CDF, and therefore we might not need it. Should be asked to Tracy Miranda 392 | 393 | 394 | ## Meeting November 9th 395 | Meeeting time in your timezone [here](https://time.is/1630_9_November_2020_in_UTC). You're welcome to join! 396 | 397 | Participants: 398 | * Emil Bäckmark, Ericsson 399 | * Mattias Linnér, Ericsson 400 | * Andreas Grimmer, Dynatrace 401 | 402 | ### Meeting time 403 | As it seems to be hard for some members to join at this time, we propose that it is rescheduled to 15.00 UTC instead (same time as SIG meeting on Thursdays). This is posted on Slack in a comment as well. 404 | 405 | ### Suggested Agenda 406 | - Is the discussion frequency good as it is or should we increase it, through using the Slack channel or comments in the HackMD document? 407 | - What about [the Standardized Metadata discussion](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/meetings.md#agenda-and-notes-1) that was brought up on last SIG meeting? How should it relate to our work in this workstream? 408 | - [Community Specification](https://github.com/CommunitySpecification/1.0), would it be interesting for us to use? 409 | 410 | ## Meeting October 26th 411 | Meeeting time in your timezone [here](https://time.is/1630_26_October_2020_in_UTC). You're welcome to join! 412 | 413 | Participants: 414 | * Emil Bäckmark, Ericsson 415 | * Mattias Linnér, Ericsson 416 | * Andrea Frittoli (IBM) 417 | * \ 418 | 419 | ### Agenda 420 | 421 | #### Meeting time 422 | - Should we stick to 16.30 UTC or should we move the meeting in accordance with daylight savings time in some way? 423 | - AP Emil: Bring this question to Slack 424 | 425 | #### Events Vocabulary 426 | https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA 427 | 428 | - We restructured the discussion section a bit 429 | - How should we document our discussions? Group on different topics? Timestamp? 430 | 431 | 432 | ## Meeting October 12th 433 | Meeeting time in your timezone [here](https://time.is/1630_12_October_2020_in_UTC). You're welcome to join! 434 | 435 | Participants: 436 | * Emil Bäckmark (Ericsson) 437 | * Ravi Lachhman (Harness) 438 | * Andrea Frittoli (IBM) 439 | 440 | ### Topics 441 | 442 | #### Meeting setup and recordings 443 | The meeting can now be joined without the Zoom client 444 | 445 | #### Events Vocabulary 446 | https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA 447 | 448 | 449 | ## Meeting September 28th 450 | Meeeting time in your timezone [here](https://time.is/1630_28_September_2020_in_UTC). You're welcome to join! 451 | 452 | Participants: 453 | * Andreas Grimmer (Dynatrace) 454 | * Emil Bäckmark (Ericsson) 455 | * Mattias Linnér (Ericsson) 456 | 457 | ### Suggested Topics 458 | 459 | #### Meeting setup and recordings 460 | AP Emil: Check with Jackie (or Tracey) on if this meeting can be held as a zoom browser meeting or just with the Zoom client. What about the recording, where is it stored? Should it be on Youtube? 461 | 462 | #### Finalize contribution to SIG Whitepaper 463 | https://docs.google.com/document/d/10m0LVTSAqltN2xNATwKS6dU8cMx08Co9-dnvvsIXD8M/edit 464 | The contribution was reviewed during the meeting and moved to the [actual whitepaper](https://docs.google.com/document/d/1Bgr6EHhW4wUTphU8xyMg87qzSee43PEA_gGdMnPHq9Q/edit#). 465 | 466 | #### Events Vocabulary 467 | https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA 468 | 469 | ## Meeting September 14th 470 | Meeeting time in your timezone [here](https://time.is/1630_14_September_2020_in_UTC). You're welcome to join! 471 | 472 | Participants: 473 | * Emil Bäckmark (Ericsson) 474 | * Mattias Linnér (Ericsson) 475 | * Andreas Grimmer (Dynatrace) 476 | * Andrea Frittoli (IBM) 477 | 478 | ### Topics 479 | 480 | #### SIG Interop Whitepaper 481 | Our contribution: https://docs.google.com/document/d/10m0LVTSAqltN2xNATwKS6dU8cMx08Co9-dnvvsIXD8M/edit 482 | 483 | Tekton project with event pipelines: https://github.com/tektoncd/plumbing 484 | 485 | #### Events Vocabulary 486 | https://hackmd.io/B-Z7mLh_Qc6frm51f3GIYA 487 | 488 | ## Meeting August 31st 489 | Meeeting time in your timezone [here](https://time.is/1630_31_August_2020_in_UTC). You're welcome to join! 490 | 491 | Participants: 492 | * Emil Bäckmark (Ericsson) 493 | * Ravi Lachhman (Harness) 494 | * Mattias Linnér (Ericsson) 495 | * Andreas Grimmer (Dynatrace) 496 | * Max Körbächer (Storm Reply) 497 | 498 | ### Potential Topics 499 | 500 | #### Kubecon Europe 501 | 502 | https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ 503 | 504 | Anyone who joined? Anything to share w.r.t. events in CI/CD? 505 | 506 | - Weaveworks presented a new version of CD GitOPS 507 | 508 | #### Common Vocabulary 509 | 510 | - Recap of last meeting discussion 511 | 512 | - Activity Started 513 | - Live Logs 514 | - Activity Finished 515 | - Status SUCCEEDED/... 516 | - Result PASSED/FAILED 517 | - Persistant Logs 518 | - Activity Canceled 519 | - Activity Triggered 520 | 521 | - Status Changed (informs e.g. about Y test cases executed or X canary releases performed) 522 | - Context: Refers to the system on which the state is changed 523 | 524 | - Collect input from Eiffel, Keptn, Tekton. And more? 525 | 526 | - AP on all: Read up on existing frameworks (linked in earlier minutes) and propose high level event terminology 527 | 528 | - AP Emil: Prepare Hackmd document for the proposal and share with the group 529 | 530 | 531 | #### SIG Interop Whitepaper 532 | ??? 533 | https://docs.google.com/document/d/1Bgr6EHhW4wUTphU8xyMg87qzSee43PEA_gGdMnPHq9Q/edit# 534 | 535 | 536 | ## Meeting August 17th 537 | Meeeting time in your timezone [here](https://time.is/1630_17_August_2020_in_UTC). You're welcome to join! 538 | 539 | Participants: 540 | * Emil Bäckmark (Ericsson) 541 | * Ravi Lachhman (Harness) 542 | 543 | ### Common Vocabulary 544 | Time to push (parts of?) this? 545 | 546 | One way to start is to define some use cases to report events using. Proposal: go for the Eiffel terminology for 'Activities'. 547 | https://github.com/eiffel-community/eiffel/tree/master/eiffel-vocabulary 548 | 549 | #### Basic For All to Understand ##### 550 | * Start 551 | * URI (link to ongoing execution) 552 | * LiveLogs (links to active logs) 553 | * Finish 554 | * Outcome 555 | * Fail 556 | * Success 557 | * PersistantLogs (links to finished logs) 558 | 559 | #### Intermediate for CI/CD Knowledge ##### 560 | * Trigger 561 | * Name 562 | * Cancel 563 | * Alerting/Monitoring/Still Processing 564 | * URI (link to ongoing execution) 565 | 566 | #### Links and/or contexts 567 | * How to connect events to each other and to the source change or other item that triggered their actions? (SIG Feedback please!) AP Emil: Present the Eiffel link model in a coming meeting. 568 | 569 | We should create: 570 | * Schema 571 | * Specification 572 | * JSON/API Docs for visualization (e.g Swagger) e.g https://www.gremlin.com/docs/api-reference/overview/ 573 | 574 | ### SIG Interop Whitepaper 575 | What should we contribute to it? 576 | * White Paper for SIG: https://docs.google.com/document/d/1Bgr6EHhW4wUTphU8xyMg87qzSee43PEA_gGdMnPHq9Q/edit# 577 | 578 | 579 | ## Meeting July 6th 580 | Meeeting time in your timezone [here](https://time.is/1630_22_June_2020_in_UTC). You're welcome to join! 581 | 582 | Participants: 583 | * Andreas Grimmer (Dynatrace) 584 | * Ravi Lachhman (Harness) 585 | * Emil Bäckmark (Ericsson) 586 | * Ramin Akhbari (eBay) 587 | * Marky Jackson (OpsMX) 588 | 589 | ### Topics 590 | 591 | #### What is an event? vs. Message, Notification, ... 592 | * Tried these definitions: 593 | * An event is something of interest that has happened in the past 594 | * A notification is a container describing such an event, to be sent over some messaging line 595 | * What does cloudevents mean with events? 596 | * Cloudevents define 'occurrence' and 'event': [Cloudevents terminology](https://github.com/cloudevents/spec/blob/v1.0/spec.md#terminology) 597 | * **We decided to stick with the [Cloudevents definitions]((https://github.com/cloudevents/spec/blob/v1.0/spec.md#terminology)) for now** 598 | 599 | #### Common vocabulary 600 | * What's the next step with the 'Rosetta Stone'? Frameworks/tools missing there? 601 | * Event: Something of interest that has occured in the past in a particular domain. 602 | * Eiffel Vocab (https://github.com/eiffel-community/eiffel/tree/master/eiffel-vocabulary) 603 | 604 | #### What is working well in the Industry? 605 | * Keptn is event driven.Follows Cloud Events spec. (https://github.com/cloudevents/spec/blob/v1.0/spec.md) 606 | 607 | #### Existing event handling frameworks 608 | What event frameworks do we know of? 609 | 610 | ##### Pure event consumers 611 | * [Tekton Triggers](https://medium.com/@dlorenc/tekton-triggers-3aba132c6344) 612 | * [Argo Events](https://github.com/argoproj/argo-events) 613 | * Various [Eiffel consumers](https://eiffel-community.github.io/) 614 | * Others? 615 | 616 | ##### Pure event producers 617 | * Various [Eiffel producers](https://eiffel-community.github.io/) 618 | * Others? 619 | 620 | ##### Both producers and consumers 621 | * [Keptn](https://keptn.sh/) ? 622 | * Tekton - Consumer [Tekton Triggers](https://medium.com/@dlorenc/tekton-triggers-3aba132c6344), Producer [Tekton event sending](https://github.com/tektoncd/pipeline/releases/tag/v0.14.0) 623 | 624 | ##### Event protocol standards (for consumers and producers) 625 | * [Eiffel](https://eiffel-community.github.io/) 626 | * [CloudEvents](https://cloudevents.io/) 627 | 628 | ### Brainstorming event formats 629 | * Event 101, "Hello SIG" 630 | 631 | 632 | ## Meeting June 22nd 633 | Meeeting time in your timezone [here](https://time.is/1630_22_June_2020_in_UTC). You're welcome to join! 634 | 635 | Participants: 636 | * Ravi Lachhman, Harness 637 | * Andreas Grimmer, Dynatrace 638 | * Emil Bäckmark, Ericsson 639 | * Ramin Akhbari, eBay 640 | * Andrea Frittoli, IBM 641 | 642 | ### Topics 643 | * Tekton Events: (Need to join the SIG/Get Access) https://docs.google.com/document/d/1ehhGngn2ulnjYX0HUxSyhQGAvcbabSa27UZs3RvZWwU/edit#heading=h.fekiyq267j9v 644 | * Google Group -> https://groups.google.com/forum/#!forum/tekton-dev 645 | * Tekton Triggers (Easy Reading) https://medium.com/@dlorenc/tekton-triggers-3aba132c6344 646 | * Readme doc: https://hackmd.io/AnVkdMb3QEeVQXKfIj4tNQ 647 | 648 | #### My First Event aka Hello/MVP Event 649 | What would be the very first event? 650 | 651 | * Start/Stop 652 | * Error 653 | * Pause 654 | * Regression 655 | * etc 656 | 657 | Tekton Trigger Start/Stop: https://github.com/tektoncd/pipeline/issues/742 658 | 659 | #### What is an event? 660 | * We re-iterated this discussion from last meeting. 661 | * Is an even only what occurs in the (CD) system? Or is it also the entity that is sent out from the system at that point? Or is that a 'Notification' about the event that occured? 662 | * To be continued in next meeting 663 | 664 | ## Meeting June 8th 665 | 666 | Participants: 667 | * Ravi Lachhman, Harness 668 | * Ramin Akhbari, eBay 669 | * Andreas Grimmer, Dynatrace 670 | * Emil Bäckmark, Ericsson 671 | * Emelie Pettersson, Ericsson 672 | 673 | Recording: https://youtu.be/l7YrA7kBw7I 674 | 675 | The intention with this initial meeting is to get a common understanding of what areas to cover in this workstream and to identify the way forward for the workstream. 676 | 677 | Zoom Bridge: https://ebay.zoom.us/j/95990976381 678 | Timezone help: https://time.is/compare/1830_8_June_2020_in_CET/EST/PST 679 | 680 | # Why we are here? 681 | * Unique benefits of Event-driven CD pipelines 682 | * Automation of CD processes 683 | 684 | # Discussion 685 | * Pipeline to Pipeline Communication 686 | * Context sent to decisions/Pipelines 687 | * What is an event? - Cloud Events Project -> https://cloudevents.io/ 688 | * Message/Envelope: Long lived and routable. 689 | * Event: Immediate, consumable. An indication. 690 | * Structure of an Event (definition). 691 | * Technology agnostic to what to be deploying to. 692 | * Harmonization of verbiage/vocabulary. -> https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md 693 | * When to Event? Trigger, Audit, Monitoring, Management 694 | * Graphing of the entire process e.g through events. What truly occurs? 695 | * Metrics about Events; e.g how many people have subscribed? Alerting around Events. 696 | 697 | # Workstream name 698 | We concluded to rename the workstream to 'events in CI/CD' to not narrow the scope of the work to just triggering or driving pipelines 699 | 700 | # Next Steps 701 | * Bi-Weekly Meetings at same time. 702 | * Read up on the CDF SIG Interop vocabulary document - https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md 703 | * Read up on events proposal for Tekton - Ramin to provide link 704 | * RA: Here's the link to Andrea Frittoli’s Actions and Notifications proposal: 705 | https://docs.google.com/document/d/1ehhGngn2ulnjYX0HUxSyhQGAvcbabSa27UZs3RvZWwU 706 | 707 | 708 | --------------------------------------------------------------------------------