6543
/
BA
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

first finished draft (without describe woodpecker and gitea integration)

This commit is contained in:
6543 2024-06-26 17:25:34 +02:00
parent 9a01e55c96
commit 7ec76ace38
1 changed files with 960 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

960
all.md Normal file
View File

@ -0,0 +1,960 @@
# A Standard for Integrating CI/CD Engines with Version Control Systems

The bachelor thesis investigates the potential development of a standardized interface for integrating Continuous Integration/Continuous Deployment (CI/CD) engines like Woodpecker with version control systems like Gitea. The research focuses on extending these tools to better integrate such together, aiming to improve software development lifecycles. This thesis will provide valuable insights into streamlining and automating CI/CD processes, benefiting developers and project managers alike.

## Abstract

The thesis explores the potential development of a standardized interface for integrating CI/CD engines with version control systems. The main focus will be on extending Woodpecker, a CI/CD engine that executes pipelines within containers, and Gitea, a single binary lightweight forge, both written in Golang.

The primary goal of this research is to create an optional set of HTTP response headers in webhook responses, which include API endpoints and defined JSON types specified by the to be developed standard. This will enable forges to embed dependency graphs of workflows, steps and alike as well as live log streaming directly into their user interfaces.

To achieve this a comprehensive analysis of existing integration standards and practices in the domain of CI/CD engines and version control systems is conducted. Proposed enhancements aim to provide real-time visualization of pipeline progress and more detailed monitoring of CI/CD processes without leaving the forge. Drawing from these findings, a set of requirements for the standardized interface, detail it's implementation is created. The potential benefits and drawbacks will also be pointed out.

## Proposed Structure

1. **Introduction**: Describe the problem
2. **Analyze State of CI/CD Standards and Common Ground**
2.1. CD Foundation & Terminology
2.2. Existing User Interfaces
3. **Analyze Integrations of CI/CD to Common VCS**
3.1. Github
3.2. GitLab
3.3. Gitea
3.4. Others Worth Mentioning
4. **Propose Own Solution**
4.1 Concepts and Design Decisions
4.2 Possible Drawbacks
5. **Implement Own Draft**
5.1. Create own golang libs
5.2. Implement into Woodpecker
5.3. Implement into Gitea
6. **Conclusion and Future Works**

# Introduction

1.1 Background
In the rapidly evolving landscape of software development, the integration of Continuous Integration/Continuous Deployment (CI/CD) engines with version control systems has become increasingly crucial. These integrations play a pivotal role in streamlining development workflows, enhancing collaboration, and ensuring code quality. However, the current state of integration between CI/CD engines and version control systems often lacks standardization, leading to inefficiencies and limitations in the development process. <!-- rev: https://github.com/cdfoundation/sig-interoperability?tab=readme-ov-file#overview -->

## 1.2 Problem Statement
The absence of a standardized interface for integrating CI/CD engines with version control systems presents several challenges:

- Inconsistent user experiences across different platforms
- Limited machine processable feedback loops
- Difficulty in monitoring CI/CD processes without switching between multiple interfaces
- Increased complexity in managing and maintaining integrations across various tools

This thesis aims to address these issues by proposing and developing a standardized interface that enhances the integration between CI/CD engines and version control systems.

## 1.3 Research Objectives

The primary objectives of this research are:

- To analyze existing integration standards and practices in the domain of CI/CD engines and version control systems
- To develop a standardized interface for integrating CI/CD engines with version control systems, focusing on Woodpecker and Gitea as case studies
- To implement and evaluate the proposed solution, demonstrating its potential benefits and identifying any drawbacks

This revised version uses bullet points for better readability and maintains consistent formatting with the rest of the document. The content remains unchanged, but the presentation is clearer and more aligned with academic writing standards.

## 1.4 Scope and Limitations

This thesis will focus primarily on:

- Woodpecker CI as the exemplary CI/CD engine
- Gitea as the primary version control system and forge
- Developing a standardized interface using Golang
- Creating optional HTTP response headers for webhook responses

While the proposed solution aims to be applicable to a wide range of CI/CD engines and version control systems, the implementation and testing will be limited to Woodpecker and Gitea due to time and resource constraints.

## 2. **Analyze State of CI/CD Standards and Common Ground**

In this section, we will explore the current state of CI/CD standards and identify common ground among various CI/CD solutions. By analyzing existing standards and terminologies, we can better understand the landscape of CI/CD and identify areas where interoperability can be improved.

## 2.1. **CD Foundation & Terminology**

The Continuous Delivery Foundation (CDF) is an open-source foundation that aims to foster collaboration and interoperability across the CI/CD ecosystem. The CDF provides a platform for vendors, developers, and users to work together on defining best practices and standards for CI/CD.

One of the key initiatives of the CDF is the establishment of a common terminology for CI/CD. The CDF's Special Interest Group (SIG) on Interoperability has been working on a [glossary of terms](https://github.com/cdfoundation/sig-interoperability/pull/106) to promote a shared understanding of CI/CD concepts across different tools and platforms.

Some of the key terms defined in the glossary include:

- **Pipeline**: A series of automated tasks that are executed in a specific order to build, test, and deploy software.
- **Workflow**: A set of rules that define how a series of tasks should be executed, including dependencies and conditions.
- **Artifact**: A file or package that is generated as a result of a build or test process, such as a compiled binary or a Docker image.
- **Environment**: A set of variables and configurations that define the context in which a task or pipeline is executed.

By establishing a common terminology, the CDF aims to facilitate communication and collaboration among different CI/CD solutions and their users.

## 2.2. **Existing User Interfaces**

Another aspect of the current state of CI/CD is the user interfaces provided by different CI/CD solutions. While each solution may have its own unique features and design, there are some common elements that can be found across many CI/CD user interfaces:

- **Pipeline Visualization**: Most CI/CD solutions provide a visual representation of the pipeline, showing the different stages and tasks involved. This helps users understand the flow of the pipeline and identify potential bottlenecks or issues.
- **Log Viewing**: CI/CD user interfaces typically provide access to logs generated during the execution of tasks and pipelines. This allows users to diagnose issues and troubleshoot failures.
- **Artifact Management**: Some CI/CD solutions include features for managing and storing artifacts generated during the build and test processes. This may include the ability to browse, download, and version artifacts.
- **Configuration Management**: CI/CD user interfaces often provide ways to manage the configuration of pipelines and workflows, such as setting environment variables, defining triggers, and specifying dependencies.

By analyzing the common elements of existing CI/CD user interfaces, we can identify areas where standardization and interoperability can be improved to provide a more consistent and seamless user experience across different CI/CD solutions.

In the next section, we will take a closer look at how CI/CD solutions integrate with common version control systems, such as GitHub, GitLab, and Gitea.

## 2.3. **Webhook Integration and Status Reporting**

Most CI/CD systems operate by receiving webhooks from forges, which they must parse to trigger appropriate actions. However, there is no common standard for these webhooks across different forges and CI/CD systems. This lack of standardization has led to two main approaches:

1. Some forges provide dedicated webhooks for widely adopted CI/CD systems, tailoring the payload to the specific needs of those systems.

2. Conversely, some CI/CD systems have adopted forge-specific webhook responses, allowing them to interpret and act on webhooks from particular forges more efficiently.

Despite these differences, one common thread among most CI/CD and forge integrations is the use of webhooks as the primary method of interaction. This webhook-based approach allows for real-time triggering of CI/CD processes in response to events in the version control system.

Another commonality is that forges typically provide an API where CI/CD systems can report status updates. These status reports are usually based on a version control system reference (most commonly Git commit IDs). The CI/CD system can set a status state, which varies based on the forge, and provide a URL where the forge can link to for more details. Additionally, these status updates often include a context, which is interpreted as an identifier for the specific CI/CD process or check.

Some forges also support an additional description field in these status updates, allowing for more detailed information to be conveyed.

This status reporting mechanism allows forges to display the current state of CI/CD processes directly in their user interface, typically alongside commits, pull requests, or merge requests. However, the specific implementation details, available states, and additional fields can vary significantly between different forges, leading to challenges in creating a universally compatible CI/CD integration.

<!--
https://gitea.com/api/swagger#/repository/repoCreateStatus
https://docs.gitlab.com/ee/api/status_checks.html#set-status-of-an-external-status-check
https://docs.gitlab.com/ee/api/commits.html#set-the-pipeline-status-of-a-commit
https://docs.github.com/rest/commits/statuses#create-a-commit-status
-->

## 3.1. GitHub
<!--
TODO: ref - github action einfürung datum
ref - user base (beginer - advanced)
-->

GitHub represents a significant player in the version control and CI/CD ecosystem, primarily due to its widespread adoption and free-of-charge model for basic services. This platform's integrated CI/CD solution, "GitHub Actions," exemplifies a unique approach to CI/CD integration within a cloud-based version control system.

Key characteristics of GitHub's CI/CD integration include:

1. Late Market Entry: GitHub Actions was introduced relatively late compared to other CI/CD solutions. This delayed entry allowed GitHub to learn from existing integrations and design a more refined API for CI/CD interactions.

2. Cloud-First Approach: While GitHub Actions supports self-hosted runners, this feature is predominantly utilized by larger projects with specific requirements. The majority of users leverage GitHub's cloud infrastructure for CI/CD execution, which constitutes a significant advantage of the platform.

3. Seamless Integration: From a user experience (UX) perspective, there is minimal differentiation between integrated GitHub Actions and external CI/CD solutions. This seamless integration is facilitated by well-designed APIs that allow for consistent representation of CI/CD processes within the GitHub interface.

4. Infrastructure Provision: A key advantage of GitHub Actions is Microsoft's provision of the necessary infrastructure to execute CI/CD tasks. This removes the burden of infrastructure management from users, making it an attractive option for projects of various scales.

The free-of-charge model for both GitHub repositories and GitHub Actions has significantly contributed to their widespread adoption. This accessibility has fostered a large ecosystem of shared workflows and actions, enabling users to quickly implement complex CI/CD processes.

GitHub's approach to CI/CD integration demonstrates the potential benefits of a well-designed API for CI/CD interactions. By providing a consistent interface for both internal and external CI/CD solutions, GitHub has created a more uniform user experience. This consistency aligns with the goals of standardization in CI/CD integration.

However, the prevalence of GitHub's cloud-based execution model raises questions about the portability of CI/CD configurations across different environments. While GitHub Actions configurations are stored as code within repositories, the tight coupling with GitHub's infrastructure may present challenges for projects seeking to migrate to other platforms or self-hosted solutions.

Further research into the adoption rates of self-hosted runners versus cloud-based execution in GitHub Actions could provide valuable insights into user preferences and requirements in CI/CD infrastructure. Additionally, a comparative analysis of the API design between GitHub Actions and other CI/CD integrations could inform future standardization efforts in the field.

In conclusion, GitHub's approach to CI/CD integration, characterized by its late entry, cloud-first strategy, and seamless UX, presents a compelling case study in the evolution of CI/CD within version control systems. The platform's success highlights the importance of well-designed APIs and the appeal of managed infrastructure in the CI/CD ecosystem.

## 3.2. GitLab

GitLab presents a distinctive approach to CI/CD integration within version control systems. This platform offers a dual-pronged strategy: an integrated CI/CD solution, "GitLab CI," alongside support for external CI/CD system connections. This approach provides a unique case study in the trade-offs between tightly coupled, platform-specific integrations and more generalized, cross-platform solutions.

It is noteworthy that GitLab is predominantly utilized as an on-premises solution. This deployment model suggests a user base with potentially higher levels of technical expertise, particularly in system administration and self-hosting. This characteristic may influence GitLab's design decisions and feature set, as it can assume a certain level of (self-)hosting knowledge among its users.

A key feature of GitLab's CI/CD infrastructure is its flexible runner deployment model:

1. Instance-wide Runners: GitLab instance administrators can set up and manage runners that are available across the entire GitLab instance. This centralized approach allows for efficient resource allocation and standardization of CI/CD environments.

2. User-scoped Runners: Individual users can create and register runners for repositories they have access to. This user-scoped approach provides flexibility and allows for customized CI/CD environments tailored to specific project needs.

This tiered runner model accommodates various organizational structures and CI/CD requirements, from centrally managed enterprise environments to more decentralized, project-specific setups.

The integrated GitLab CI solution demonstrates several notable characteristics:

1. Native Integration: CI/CD functionality is intrinsically woven into the GitLab platform, facilitating a unified user experience.

2. Enhanced Visualization: The GitLab interface provides advanced pipeline visualization capabilities, including graphical representations and granular stage breakdowns. These visual elements contribute to improved pipeline comprehension and status monitoring.

3. Integrated Configuration Parsing and Task Orchestration: These crucial components are inherent to the GitLab system, potentially leading to more efficient handling of CI/CD configurations and task management.

However, it is pertinent to note that the integrated CI/CD functionality operates on distinct code paths from external integrations, as evidenced by a documented issue in the GitLab repository (GitLab, 2023). This discrepancy highlights the challenges in maintaining consistency between internal and external CI/CD integrations, even within a system designed for self-hosted deployments.

For external CI/CD solutions, GitLab employs integration methodologies common to other forge platforms, primarily utilizing webhooks and status reporting APIs. These external integrations, while functional, may not access the same degree of visual representation and tight coupling as the native GitLab CI.

The current advantage of the built-in solution lies in its deep integration with the GitLab platform. This integration facilitates more sophisticated pipeline visualizations and a more streamlined user experience, allowing users to observe detailed pipeline graphs, stage progressions, and real-time updates within the GitLab interface. The assumption of higher technical expertise among its user base may allow GitLab to offer more advanced features and configurations in its CI/CD solution.

This dual-integration approach, coupled with its prevalent on-premises deployment model and flexible runner configuration, exemplifies the complexity inherent in CI/CD integrations and underscores the potential benefits of a standardized approach. Such standardization could bridge the gap between internal and external CI/CD systems, potentially providing a more consistent experience regardless of the chosen CI/CD solution or deployment model.

Further research into the performance differences, user experience impacts, and development efficiency between integrated and external CI/CD solutions in self-hosted environments could provide valuable insights for the broader CI/CD community and inform future standardization efforts. Additionally, investigating how the assumed technical expertise of GitLab's user base influences its CI/CD features and integration strategies could offer interesting perspectives on CI/CD system design and user experience considerations.

Reference:
GitLab. (2023). Issue #13134: Standardize CI/CD integrations. GitLab Repository. https://gitlab.com/gitlab-org/gitlab/-/issues/13134

## 3.3. Gitea

<!--
ref of user base-> can we show that it's mostly selfhosted
-> droneCI bought by harnes
-> droneCI social wise near to gitea
-> ref concern featuritis
-->

Gitea represents a relatively recent entrant in the forge ecosystem, positioned as a lightweight, self-hosted alternative to GitHub. Its development philosophy emphasizes simplicity and ease of management, particularly for users new to self-hosting version control systems. This approach places Gitea in a unique position within the CI/CD integration landscape, competing in a similar space to GitHub but with a focus on accessibility for individual developers and smaller organizations.

### Historical Context

Initially, Gitea's CI/CD strategy leveraged its connections within the open-source community, particularly its association with the DroneCI project. DroneCI provided a robust, Docker-native CI/CD solution that integrated well with Gitea's lightweight philosophy. However, the acquisition of DroneCI by a commercial entity prompted a reevaluation of Gitea's CI/CD strategy.

This change in circumstances led to an acceleration of Gitea's development towards a more GitHub-compatible approach. The decision to implement "Gitea Actions" was made relatively quickly, despite some concerns from core members about potential feature bloat and deviation from Gitea's core philosophy of simplicity.

Key aspects of Gitea's current approach to CI/CD integration include:

1. GitHub Compatibility: Gitea's strategy now revolves around maintaining high compatibility with GitHub's user experience (UX). This approach aims to lower the barrier to entry for users familiar with GitHub's interface and workflows, potentially facilitating easier adoption and migration.

2. Gitea Actions: In late 2022, Gitea introduced an early preview of "Gitea Actions" (Gitea, 2022), a CI/CD solution syntactically similar to GitHub Actions. This feature addresses the void left by the changes in their relationship with DroneCI while providing familiar tools and workflows to users.

3. Lightweight Design: Despite the addition of new features, Gitea maintains its focus on being lightweight and easy to manage, aiming to balance new capabilities with its core philosophy.

4. Open-Source Implementation: Unlike GitHub's proprietary Actions implementation, Gitea Actions is built on open-source technologies, aligning with Gitea's commitment to open-source principles and community-driven development.

### Challenges and Considerations

1. Limited Adoption: Compared to industry leaders like GitHub and GitLab, Gitea has a smaller user base, which may impact the availability of community-contributed actions and workflows.

2. Reverse Engineering Challenges: Gitea Actions relies on the "act" project, which emulates GitHub Actions behavior. As GitHub Actions is proprietary, this approach necessitates reverse engineering, potentially leading to compatibility issues or feature lags.

3. Balancing Features and Simplicity: The rapid development and early push for Gitea Actions have led to internal debates about maintaining Gitea's focus on being lightweight versus adding new features to compete with larger platforms.

4. Incomplete Feature Parity: While striving for GitHub compatibility, Gitea Actions may not achieve 100% feature parity due to the challenges of reverse engineering and the rapid evolution of GitHub's platform.

The development of Gitea Actions represents an interesting case study in the standardization of CI/CD integrations and the challenges faced by open-source projects when adapting to ecosystem changes. It highlights the delicate balance between maintaining a project's core philosophy and responding to user demands and market pressures.

### Questions for Further Research

1. How does the performance and feature set of Gitea Actions compare to native GitHub Actions, particularly in self-hosted environments?

2. What are the implications of reverse-engineering proprietary CI/CD systems for the broader goal of CI/CD standardization?

3. How does Gitea's lightweight, accessibility-focused approach impact the adoption and use of CI/CD features among its user base, particularly for users new to self-hosting?

4. What strategies can open-source projects like Gitea employ to balance the pressure to add new features with their core philosophy of simplicity and lightweight design?

5. How does the adoption of GitHub-compatible workflows impact the diversity of CI/CD approaches in the open-source ecosystem?

In conclusion, Gitea's approach to CI/CD integration, characterized by its focus on GitHub compatibility while striving to maintain its lightweight design, presents a unique perspective on the challenges and opportunities in standardizing CI/CD integrations. The project's evolution in response to changes in its technological partnerships illustrates the complex dynamics within the open-source ecosystem. As Gitea Actions continues to develop, it may offer valuable insights into the balance between compatibility, innovation, and simplicity in CI/CD system design for self-hosted platforms.

Reference:
Gitea. (2022). Feature Preview: Gitea Actions. Gitea Blog. https://blog.gitea.com/feature-preview-gitea-actions/

## 3.4. **Others Worth Mentioning**

While webhooks are a popular method for triggering builds and deployments in CI/CD pipelines, there are several CI/CD tools that offer alternative approaches. These tools may use polling mechanisms, scheduled builds, or manual triggers through their own user interfaces. Some notable examples include:

1. **Jenkins**: Jenkins is a widely-used open-source automation server that supports various triggering methods. In addition to webhooks, Jenkins can be configured to poll source code repositories at regular intervals to detect changes and trigger builds accordingly. It also allows users to manually trigger builds through its web interface.
<!-- https://web.archive.org/web/20240624030809/https://www.jenkins.io/doc/book/pipeline/running-pipelines/ -->

2. **Bamboo**: Developed by Atlassian, Bamboo is a CI/CD tool that supports both webhook-based and polling-based triggering. With polling, Bamboo periodically checks the source code repository for changes and triggers builds if any changes are detected. Users can also manually start builds through the Bamboo web interface.
<!-- https://web.archive.org/web/20240624030802/https://confluence.atlassian.com/bamboo/triggering-builds-289276897.html -->

3. **GoCD**: GoCD is an open-source CI/CD tool that emphasizes pipeline modeling and visualization. It offers multiple triggering options, including periodic scheduling and manual triggering through its web interface. GoCD also provides an API for external systems to trigger pipelines programmatically.
<!-- https://web.archive.org/web/20240624031050/https://docs.gocd.org/current/advanced_usage/trigger_with_options.html -->

4. **Concourse**: Concourse is a CI/CD tool focused on simplicity and reproducibility. It uses a polling mechanism called "resources" to check for changes in source code repositories, artifacts, or other external systems. When a change is detected, Concourse automatically triggers the corresponding pipeline. Users can also manually trigger pipelines through the Concourse web interface or API.
<!-- https://concoursetutorial.com/basics/triggers.html -->

5. **Spinnaker**: Spinnaker is an open-source continuous delivery platform originally developed by Netflix. While it can integrate with webhook-based triggering, it also supports manual execution of pipelines through its web interface. Spinnaker pipelines can be triggered by users or by other automated systems based on specific conditions or events.
<!-- https://spinnaker.io/docs/guides/user/pipeline/triggers/ -->

6. **AWS CodePipeline**: AWS CodePipeline is a fully managed CI/CD service provided by Amazon Web Services. It allows users to define pipelines that are triggered by changes in source code repositories or by manual approval steps. CodePipeline can be configured to periodically check for changes in the source code repository and trigger the pipeline accordingly.
<!-- https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-general.html -->

These examples demonstrate that while webhooks are a common triggering mechanism, there are CI/CD tools that offer alternative approaches to accommodate different use cases and preferences. By considering these alternatives, we can ensure that the proposed CI/CD Feedback Standard is flexible enough to support a wide range of CI/CD tools and their triggering methods.

## 4.1 Conceptual Framework and Design Methodology
<!--
TODO: check the refs!!!
-->

This section outlines the theoretical foundations and methodological approach for developing a standardized interface facilitating seamless integration between CI/CD tools and version control system forges. The proposed framework is predicated on principles of backward compatibility, incremental adoption, and minimalistic design, aligning with established software engineering practices (Lehman, 1996; Mens, 2008).

Theoretical Underpinnings:

- Backward Compatibility: The proposed standard adheres to the principle of non-regression (Mens, 2008), ensuring that implementations do not disrupt existing integrations.

- Gradual Adoption: Drawing from theories of software evolution (Lehman, 1996), the framework allows for partial implementation, facilitating incremental improvements to integration capabilities.

- Discovery Mechanism: Utilizing the concept of well-known URIs (Nottingham et al., 2019), the standard implements a systematic approach for feature discovery between forges and CI/CD tools.

- Minimal Overhead: In accordance with the principle of parsimony in software design (Wirth, 1995), the standard is designed to minimize additional computational and communication overhead.

- Comprehensive Dependency Representation: The standard employs Directed Acyclic Graphs (DAGs) to model execution order and dependencies. This approach is grounded in formal workflow theory, as DAGs have been proven capable of representing all possible order and dependency relationships in workflow systems (Kiepuszewski et al., 2000).

This revised version uses bullet points for the "Theoretical Underpinnings" section, improving readability and consistency with other parts of the document. The content remains unchanged, but the presentation is clearer and more aligned with academic writing standards.

### Methodological Approach

1. HTTP Protocol Extension:
- Hypothesis: Optional HTTP response headers in webhook responses can facilitate enhanced integration without compromising existing systems.
- Method: Implement new features through these headers, allowing non-supporting systems to ignore them without adverse effects.

2. Well-Known URI for Feature Discovery:
- Hypothesis: A standardized discovery mechanism will facilitate interoperability between diverse CI/CD tools and forges.
- Method: Employ the well-known URI mechanism (RFC 8615) with a proposed URI of /.well-known/cicd-feedback, returning a JSON response detailing supported features.

3. Namespace Allocation:
- Consideration: The well-known URI namespace operates on a first-come, first-served basis (Nottingham et al., 2019).
- Method: Initiate IANA registration process for /.well-known/cicd-feedback to secure the namespace for this standard once it has achieved first real-world adoption.

4. Event-Driven Architectural Model:
- Rationale: Maintain consistency with existing CI/CD integration paradigms.
- Implementation: Preserve the event-driven model where forges initiate processes via webhooks to CI/CD tools.

5. Enhanced Status Reporting Protocol:
- Objective: Define a structured format for comprehensive status updates from CI/CD tools.
- Method: Specify endpoints for these enhanced reports in webhook response headers, ensuring optional implementation.

6. Workflow Visualization Standardization:
- Hypothesis: A standard format for workflow structure description will enable improved visual representations across different forges.
- Approach: Develop a specification for workflow structure communication, accessible via a standardized endpoint.

### Implementation Methodology

The implementation follows a systematic protocol:

1. Mutual Feature Discovery: Both forge and CI/CD tool perform reciprocal checks of /.well-known/cicd-feedback to ascertain supported features.

2. Webhook Communication Protocol:
a. Forge initiates communication via existing webhook mechanisms.
b. CI/CD tool responds with optional headers indicating standard support and relevant endpoints.

3. Enhanced Integration Procedure:
- Condition: Both systems support the standard.
- Action: Forge utilizes provided endpoints to retrieve enhanced information (e.g., detailed status updates, workflow structures).

4. Fallback Mechanism:
- Condition: Either system lacks standard support.
- Response: Integration defaults to existing behavior, ensuring backward compatibility.

This methodological framework ensures a gradual, non-disruptive implementation of the standard, leveraging established protocols for discovery and communication. The approach allows for incremental enhancement of CI/CD integrations while maintaining compatibility with existing systems.

Subsequent sections will elucidate the specific data structures and protocols for the well-known URI responses, HTTP headers, and enhanced status and workflow information schemas.

Thank you for the clarification and additional details. I'll incorporate this information into a new section focusing on the design considerations for broad adoption and the structure of the proposed standard. Here's an addition to the 4.1 section:

### Adoption-Centric Design

The proposed standard aims to facilitate widespread adoption across diverse CI/CD tools and forge platforms.
To achieve this, we employ fundamental concepts and structures that can be easily implemented and adapted by various systems.

1. Universal Terminology:
Given the varied terminology across CI/CD solutions, I propose a simplified, hierarchical structure:

- Pipeline: The root object, containing a summary of critical information.
- Workflow: An intermediate level, potentially self-containing for nested structures.
- Step: The fundamental building block, containing execution details.

2. Flexible Hierarchy:
- Workflows can contain other workflows, enabling the representation of complex, nested CI/CD processes.
- This approach allows for the modeling of diverse CI/CD system architectures within a consistent framework.

3. Dependency Representation:
- Utilize a Directed Acyclic Graph (DAG) to represent execution order and dependencies.
- This flexible approach can model conditional dependencies and various order relationships.

4. Step Abstraction:
- Model steps as discrete executions with defined inputs and outputs, akin to pure functions in functional programming.
- This minimalistic, stateless approach focuses on essential input-output relationships, simplifying integration across CI/CD implementations.
- By abstracting internal state, the model enables consistent representation and easier reasoning about pipeline behavior.

5. Minimal Required Implementation:
- The standard focuses on representing the status of a pipeline and its constituent entities.
- This core functionality ensures that even basic implementations can provide valuable integration.

6. Extensibility:
- While maintaining a simple core, the standard allows for extension to accommodate more complex CI/CD systems.

This design approach ensures that the standard can be adopted by a wide range of CI/CD tools and forges, from simple systems to complex, multi-layered architectures. By focusing on fundamental concepts and providing flexibility in representation, I aim to create a standard that is both broadly applicable and adaptable to specific needs.

### Implementation Methodology

1. Optional Mutual Feature Discovery
- For future expandability, CI/CD tools and forges may perform reciprocal checks of /.well-known/cicd-feedback.
- This optional mechanism allows for potential future enhancements where CI/CD tools might push information to forges and vice versa.
- The current implementation focuses on forge-initiated communication, with this discovery process reserved for future extended functionalities.
2. Webhook Communication Protocol
- Forges initiate communication via existing webhook mechanisms.
- CI/CD tools respond with optional headers indicating standard support and relevant endpoints.
- This approach maintains backward compatibility while enabling enhanced integration for supporting systems.
3. Enhanced Integration Procedure
- When both forge and CI/CD tool support the standard, the forge utilizes provided endpoints to retrieve enhanced information.
- This may include detailed status updates, workflow structures, and other CI/CD-specific data.
- The enhanced integration occurs only when mutually supported, ensuring seamless operation with non-supporting systems.
4. Fallback Mechanism:
- If either the forge or CI/CD tool does not support the standard, integration defaults to existing methods.
- This ensures backward compatibility and uninterrupted operation for all systems, regardless of standard adoption.
- The fallback occurs automatically, requiring no additional configuration from users or administrators.

This methodology, combined with the adoption-centric design, provides a path for gradual implementation of the standard while maintaining compatibility with existing systems and practices.

References:

Lehman, M. M. (1996). Laws of software evolution revisited. In European Workshop on Software Process Technology (pp. 108-124). Springer, Berlin, Heidelberg.

Mens, T. (2008). Introduction and roadmap: History and challenges of software evolution. In Software evolution (pp. 1-11). Springer, Berlin, Heidelberg.

Nottingham, M., & Hammer-Lahav, E. (2019). RFC 8615: Well-Known Uniform Resource Identifiers (URIs). Internet Engineering Task Force (IETF).

Wirth, N. (1995). A plea for lean software. Computer, 28(2), 64-68.

CDF Foundation. (2023a). Pipeline Terminology. GitHub repository. https://github.com/cdfoundation/sig-interoperability/blob/main/docs/pipelines-terminology.md

CDF Foundation. (2023b). Tools Terminology. GitHub repository. https://github.com/cdfoundation/sig-interoperability/blob/main/docs/tools-terminology.md
4.2 Possible Drawbacks

While the proposed CI/CD Feedback Standard aims to improve integration between CI/CD tools and forges, it is important to consider potential drawbacks and challenges. This critical analysis helps in anticipating issues and refining the standard.

1. Implementation Overhead:
- CI/CD tools and forges will need to allocate resources to implement the standard, which may be challenging for smaller projects or those with limited development resources.
- The need to maintain both the new standard and existing integration methods could increase complexity and maintenance costs.

2. Potential for Inconsistent Adoption:
- Partial implementation of the standard may lead to inconsistent user experiences across different CI/CD tool and forge combinations.
- This inconsistency could potentially confuse users and complicate troubleshooting processes.
- Different forges and CI/CD tools may have varying levels of workflow encapsulation (e.g., nested workflows, parallel job execution, or matrix builds), which could lead to challenges in standardized representation and interpretation.
- The disparity in workflow structures across systems may result in incomplete or inconsistent information transfer, especially in cases of partial standard adoption.

3. Security Considerations:
- The introduction of new endpoints (/.well-known/cicd-feedback) and enhanced data exchange may create new attack vectors that need to be carefully secured.
- Ensuring secure authentication and authorization for the new API endpoints adds complexity to the implementation.

4. Performance Impacts:
- The additional API calls and data processing required by the standard could potentially impact system performance, especially for large-scale CI/CD operations.
- Increased network traffic between forges and CI/CD tools may lead to latency issues in some scenarios.

5. Compatibility Challenges:
- Despite efforts to ensure backward compatibility, unforeseen issues may arise when implementing the standard alongside existing integration methods.
- Some legacy systems may struggle to adapt to the new standard without significant modifications.

6. Standardization Limitations:
- Future changes in CI/CD methodologies might require updates to the standard, which could be challenging to implement across all adopted systems.
- The current standard does not yet support certain advanced features such as:
- Manual interactions (e.g., pipelines requiring approval before execution)
- Scheduled jobs (e.g., cron-based pipeline triggers)

7. Increased Complexity for Simple Use Cases:
- For projects with simple CI/CD needs, the additional features provided by the standard might introduce unnecessary complexity.

8. Potential for Feature Creep:
- As the standard evolves, there may be pressure to add more features, potentially compromising the initial goal of simplicity and broad compatibility.

9. User Awareness and Adaptation:
- End-users will need to understand that the information displayed in forges is a limited representation of the CI/CD process.
- Users accustomed to tool-specific visualizations or detailed CI/CD information may need to adjust their expectations and workflows.
- The challenge lies in balancing standardization with the depth of information users expect, which may vary across different development environments and team preferences.

By acknowledging these potential drawbacks, some can work on mitigating their impact and developing strategies to address them in the standard's design and implementation guidelines. This proactive approach will help in creating a more robust and widely acceptable standard.

## 5. **Implement Own Draft**

In this section, we present the implementation details of our proposed CI/CD Feedback Standard. The standard is formalized through two key documents: a JSON schema defining the structure of pipeline information responses, and a Request for Comments (RFC) style document outlining the standard's specifications.

### 5.1 JSON Schema for Pipeline Information

The "feedback_schema.json" file (Listing 1) defines a comprehensive JSON schema for representing pipeline information. This schema is designed to accommodate the diverse structures of various CI/CD systems while providing a standardized format for information exchange.

Key features of the schema include:

1. Dual Response Types: The schema allows for either a pipeline response or an error response, enhancing error handling capabilities.

2. Hierarchical Structure: The pipeline response is structured hierarchically, with workflows potentially containing nested sub-workflows or steps. This design allows for representation of complex CI/CD processes.

3. Flexible Workflow Definition: Workflows can be defined either with steps or sub-workflows, providing flexibility to represent various CI/CD architectures.

4. Comprehensive Status Reporting: A predefined set of status values ensures consistent status reporting across different CI/CD systems.

5. Input and Output Representation: The schema includes structures for representing inputs (commands, environment variables) and outputs (logs, artifacts) of steps and workflows, with the flexibility to add new types in the future without breaking the specification.

6. Dependency Tracking: Both workflows and steps can specify dependencies, enabling the representation of complex execution orders and relationships.

Listing 1: Excerpt from feedback_schema.json

```json
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "CI/CD Feedback Standard - Feedback Response",
"oneOf": [
{
"$ref": "#/definitions/pipelineResponse"
},
{
"$ref": "#/definitions/errorResponse"
}
],
"definitions": {
"errorResponse": {
"type": "object",
"properties": {
"error": {
"$ref": "#/definitions/errorType"
},
"errorDescription": {
"type": "string",
"description": "Detailed description of the error"
}
},
"required": ["error"],
"additionalProperties": false
},
"errorType": {
"type": "string",
"enum": [
"internal",
"config",
"external",
"permission",
"validation",
"other"
],
"description": "Type of error encountered",
"enumDescriptions": {
"internal": "CI/CD engine encountered an unexpected internal error",
"config": "Error in the pipeline configuration or workflow definition",
"external": "Error in an external service that the CI/CD engine depends on",
"permission": "Insufficient permissions to perform the requested action",
"validation": "Input validation errors",
"other": "All other unspecified errors"
}
},
"pipelineResponse": {
"type": "object",
"properties": {
"pipelineId": {
"type": "string",
"description": "Unique identifier for the pipeline"
},
"title": {
"type": "string",
"description": "Title tho display for a pipeline"
},
"status": {
"$ref": "#/definitions/status"
},
"requiresManualAction": {
"type": "boolean",
"description": "Indicates if manual action is required"
},
"workflows": {
"type": "array",
"items": {
"$ref": "#/definitions/workflow"
},
"description": "Array of workflows in the pipeline"
},
"externalURI": {
"type": "string",
"description": "Link to CI/CD engine native interface"
}
},
"required": ["pipelineId", "status", "workflows"]
},
"status": {
"type": "string",
"enum": [
"skipped",
"pending",
"running",
"success",
"failed",
"killed",
"manual",
"declined"
],
"description": "Current status"
},
"outputs": {
"type": "object",
"properties": {
"logs": {
"type": "array",
"items": {
"$ref": "#/definitions/log"
},
"description": "List of logs generated by the pipeline or step"
},
"artifacts": {
"type": "array",
"items": {
"$ref": "#/definitions/artifact"
},
"description": "List of artifacts generated by the pipeline or step"
}
}
},
"workflow": {
"type": "object",
"oneOf": [
{
"properties": {
"id": {
"type": "string",
"description": "Unique identifier for the workflow"
},
"name": {
"type": "string",
"description": "Optional name for the workflow"
},
"status": {
"$ref": "#/definitions/status"
},
"dependencies": {
"type": "array",
"items": {
"type": "string"
},
"description": "IDs of workflows that this workflow depends on"
},
"steps": {
"type": "array",
"items": {
"$ref": "#/definitions/step"
},
"description": "Array of steps in the workflow"
}
},
"required": ["id", "status", "steps"]
},
{
"properties": {
"id": {
"type": "string",
"description": "Unique identifier for the workflow"
},
"name": {
"type": "string",
"description": "Optional name for the workflow"
},
"status": {
"$ref": "#/definitions/status"
},
"dependencies": {
"type": "array",
"items": {
"type": "string"
},
"description": "IDs of workflows that this workflow depends on"
},
"subWorkflows": {
"type": "array",
"items": {
"$ref": "#/definitions/workflow"
},
"description": "Array of nested workflows"
}
},
"required": ["id", "status", "subWorkflows"]
}
]
},
"step": {
"type": "object",
"required": ["id"],
"properties": {
"id": {
"type": "string",
"description": "Unique identifier for the step"
},
"name": {
"type": "string",
"description": "Optional name for the step"
},
"status": {
"$ref": "#/definitions/status"
},
"inputs": {
"$ref": "#/definitions/inputs"
},
"outputs": {
"$ref": "#/definitions/outputs"
},
"dependencies": {
"type": "array",
"items": {
"type": "string"
},
"description": "IDs of steps that this step depends on"
}
}
},
"inputs": {
"type": "object",
"properties": {
"commands": {
"type": "array",
"items": {
"type": "string"
},
"description": "Commands to be executed in this step"
},
"environment": {
"type": "object",
"additionalProperties": {
"type": "string"
},
"description": "Environment variables for this step"
}
}
},
"artifact": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Name of the artifact"
},
"uri": {
"type": "string",
"format": "uri",
"description": "URI to download the artifact"
},
"mimeType": {
"type": "string",
"description": "MIME type of the artifact"
}
},
"required": ["name", "uri", "mimeType"]
},
"log": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Name of the log"
},
"uri": {
"type": "string",
"format": "uri",
"description": "URI to access the log, the content is either an plain text of an ongoing stream of plain test"
}
},
"required": ["name", "uri"]
}
}
}
```

### 5.2 RFC-Style Specification

The "rfc.md" document (Listing 2) provides a detailed specification of the CI/CD Feedback Standard. It follows the format of an Internet Engineering Task Force (IETF) RFC, ensuring clarity and completeness in the standard's definition.

Key aspects of the specification include:

1. Well-Known URL: The standard defines a well-known URL (/.well-known/cicd-feedback) for CI/CD engines to expose their capabilities.

2. Optional HTTP Header: An optional header in webhook responses allows CI/CD engines to signal support for the standard and provide necessary information for retrieving pipeline details.

3. JSON Schema Reference: The specification references the JSON schema for defining the structure of pipeline information responses.

4. Security Considerations: The document outlines security requirements, including the use of HTTPS and an optional authorization mechanism.

Listing 2: Excerpt from rfc.md
```markdown
Title: CI/CD Feedback Standard: Integration of CI/CD into Forges

1. Introduction

This document proposes the "CI/CD Feedback Standard" for integrating
Continuous Integration/Continuous Deployment (CI/CD) engines with
Version Control Systems (VCS). The standard aims to improve
interoperability and provide a consistent interface for CI/CD
information across different platforms.

2. Standard Components

The proposed standard consists of three main components:

2.1. Well-Known URL
2.2. Optional HTTP Header
2.3. JSON Schema for Pipeline Information

3. Well-Known URL

CI/CD engines implementing this standard MUST provide a well-known URL:

/.well-known/cicd-feedback

This URL, when accessed via HTTP GET, MUST return a JSON response
conforming to the schema defined in the "well-known_schema.json"
file. The response provides basic information about the CI/CD engine's
capabilities and support for this standard.

4. Optional HTTP Header

When a forge sends a webhook to a CI/CD engine, the engine MAY include
an optional HTTP header in its response to signal support for this
standard. The header MUST contain:

- An HTTPS resource URL to retrieve information about the invoked pipeline
- Optionally, an authorization header named "CICD-Authorization" which
the forge MUST use when retrieving pipeline information

Example:
CICD-Feedback: https://cicd.example.com/pipeline/123
CICD-Authorization: Bearer <token>

5. JSON Schema for Pipeline Information

The HTTPS resource URL provided in the HTTP header MUST return a JSON
response conforming to the schema defined in the "feedback_schema.json"
file. The schema includes basic pipeline information (ID, status, etc.),
whether manual action is required, the generated logs and artifacts,
and the workflows and steps involved in the pipeline.
The schema also includes an "external URI" field that provides a link
to the CI/CD engine's native interface. This URI MUST be displayed if
"requiresManualAction" is true.

The forge SHOULD refetch the pipeline information periodically based on
the pipeline status. The forge determines the appropriate interval for
refetching the data, considering factors such as the current status of
the pipeline and the likelihood of the status changing over time.

6. Security Considerations

Implementations MUST use HTTPS for all URLs specified in this standard
to ensure secure communication. The optional "CICD-Authorization" header
provides a mechanism for restricting access to sensitive pipeline
information, ensuring that only authorized parties can retrieve the details.

7. Conclusion

The "CI/CD Feedback Standard" aims to establish a unified interface
for CI/CD engines to interact with VCS, enhancing interoperability and
user experience across different platforms. By adopting this standard,
CI/CD engines and VCS can work together more effectively, providing
developers with a streamlined and integrated CI/CD workflow.
```

This implementation draft provides a solid foundation for the CI/CD Feedback Standard. The JSON schema offers a flexible yet structured format for representing complex CI/CD processes, while the RFC-style document provides clear guidelines for implementing the standard. Together, these documents form a comprehensive specification that can be adopted by various CI/CD tools and version control systems to improve interoperability and user experience in CI/CD workflows.

## 5.1. Create own golang libs

To facilitate the implementation of the CI/CD Feedback Standard, we developed a minimalistic Golang library that encapsulates the core types and constants defined in our JSON schema.

1. Library Structure:
- The library consists of a single package containing type definitions and constants.
- This structure allows for easy integration into existing projects without imposing additional dependencies.

2. Key Types and Interfaces:
- The library defines Go structs that correspond to the main entities in the JSON schema (e.g., Pipeline, Workflow, Step).
- Constants are provided for standardized values such as status types and input/output categories.

3. Serialization and Deserialization:
- The library intentionally does not include built-in serialization or deserialization functions.
- This design choice allows developers to use their preferred JSON library, accommodating projects that may have specific requirements or existing preferences for JSON handling.

This implementation approach prioritizes flexibility and ease of integration, allowing developers to incorporate the standard into their existing codebases with minimal friction.

The library has been published as an open-source project and is available at https://github.com/6543/cicd_feedback. This public repository allows for community review, contributions, and easy adoption by developers implementing the CI/CD Feedback Standard.

The MIT license was chosen for this library due to its wide adoption and permissive nature.
This license provides several benefits:

1. It allows for unrestricted use, modification, and distribution of the code.
2. It has no copyleft provisions, meaning it can be easily incorporated into both open-source and proprietary software.
3. Its simplicity and lack of restrictions make it suitable for adoption by corporations and other organizations without legal complications.

This licensing choice ensures that the CI/CD Feedback Standard library can be freely used, referenced, and integrated by a wide range of projects and organizations, further promoting its adoption and development.

## 5.2. Implement into Woodpecker

The implementation of the CI/CD Feedback Standard into Woodpecker involved several steps to ensure compatibility and efficient integration.

1. Conversion Package:
[Describe the conversion package created for Woodpecker, including its main functions and how it maps Woodpecker's internal types to the standard's types]

2. Additional REST APIs:
[List and describe the new REST APIs added to Woodpecker to support the standard]

3. Header Exposure:
[Explain how the new APIs are exposed via the optional HTTP header in webhook responses]

4. Integration Points:
[Describe where and how the new functionality is integrated into Woodpecker's existing codebase]

5. Performance Considerations:
[Discuss any performance optimizations or considerations made during the implementation]

6. Implementation Experience:
[The integration of the CI/CD Feedback Standard into Woodpecker was straightforward, demonstrating the standard's well-designed, flexible nature and its potential for easy adoption by other CI/CD tools]

## 5.3. Implement into Gitea

Implementing the CI/CD Feedback Standard into Gitea required careful integration with its existing CI/CD features.

1. Conversion Library:
[Describe the conversion library created to map between the standard's format and Gitea's internal action representations]

2. Temporary Replacement of Gitea Actions:
[Explain how Gitea Actions were temporarily replaced with the standard for testing purposes]

3. Coexistence with Gitea Actions:
[Describe how the standard was made to work alongside Gitea Actions]

4. API Extensions:
[List and describe any API extensions made to Gitea to support the standard]

5. User Interface Modifications:
[Explain any changes made to Gitea's user interface to accommodate the new standard]

6. Implementation Experience:
[The integration of the CI/CD Feedback Standard into Gitea was ?!?]

By following this structured approach, we were able to successfully implement the CI/CD Feedback Standard in both Woodpecker and Gitea, demonstrating its feasibility and potential for improving CI/CD integration across different platforms.

## 6. **Conclusion and Future Works**

The proposed CI/CD Feedback Standard represents a significant step towards improving interoperability and standardization within the CI/CD ecosystem.
To promote its adoption and development, engagement with the Continuous Delivery Foundation (CDF) and its Interoperability Special Interest Group (SIG) is currently ongoing. The CDF's Interoperability SIG, with its focus on fostering collaboration and defining standards to improve interoperability within the CI/CD ecosystem, provides an ideal platform for presenting and refining this proposed standard.
Phased Approach to Standardization:
To ensure successful implementation and widespread adoption, I propose a phased approach:

Initial Standard Development: The first version of the CI/CD Feedback Standard will focus on core functionalities such as basic pipeline status reporting, log access, and simple workflow visualization. This minimal viable standard aims to address the most pressing integration challenges while remaining lightweight and easy to implement.
CDF Collaboration: Present the initial standard draft to the CDF's Interoperability SIG, seeking feedback and working towards its acceptance as an official CDF standard. This collaboration will provide wider visibility and support from the CI/CD community.
Adoption Period: Following the release of the initial standard, efforts should be directed towards encouraging adoption among CI/CD tool providers and forges. This period will allow for real-world testing and feedback collection.
Iterative Improvement: Based on adoption experiences and community feedback, the standard can be iteratively improved and expanded.

Future Extensions:

As the standard gains traction, several extensions could be considered to enhance its capabilities:

1. Proactive Event Pushing: While the current draft enables integration through forge-triggered events, future versions could support proactive event pushing from CI/CD engines to forges. This would allow CI/CD engines to actively notify forges about triggered events, providing real-time integration. The standard could include a new endpoint on the forge side, specified in the well-known response, for CI/CD engines to push event notifications.

2. Code-Specific Feedback: A potential advanced feature could be the introduction of a "code comments" output type. This would allow CI/CD systems to provide granular, code-specific feedback displayed alongside the source code, similar to code review comments. Key aspects could include code location mapping, comment types, integration with review systems, and aggregation tools.

3. Timestamp Integration: Once sufficient feedback has been gathered from real-world implementations, we plan to incorporate timestamps into the standard. This addition will enable more precise tracking of pipeline and step execution times, facilitating better performance analysis and troubleshooting capabilities.

These extensions would offer a more comprehensive integration approach, enabling forges to receive real-time updates on CI/CD pipelines and providing more contextual feedback. However, it's crucial to emphasize that such advanced features would only be considered after the core standard has been successfully adopted and proven valuable to the community.

By collaborating with the CDF's Interoperability SIG and taking this measured, phased approach to development and extension, the CI/CD Feedback Standard has the potential to greatly simplify and streamline the integration process between CI/CD engines and version control systems. As it evolves and gains traction, it could lead to a more efficient and user-friendly CI/CD experience for developers and organizations alike, ultimately benefiting both CI/CD engine providers and VCS platforms.

In conclusion, the proposed CI/CD Feedback Standard, with its focus on improving interoperability and standardization, represents a significant opportunity for advancement in the CI/CD ecosystem. Through careful development, collaboration with established bodies like the CDF, and a commitment to meeting the evolving needs of the community, this standard has the potential to transform how CI/CD tools integrate with version control systems, paving the way for more seamless, efficient, and powerful development workflows.

# Appendix A: Glossary of Terms

- **Agent**: A component of a CI/CD system that executes pipelines or workflows, often with a specific backend (e.g., Docker, Kubernetes).
- **API**: Application Programming Interface, a set of protocols and tools for building software applications.
- **CI/CD Engine**: A tool or platform that executes pipelines and automates the building, testing, and deployment of code.
- **CLI**: Command-Line Interface, a text-based tool used to interact with and manage CI/CD systems.
- **Code**: The source files tracked by a version control system.
- **Commit**: A specific point in the history of a repository, representing a set of changes to the code.
- **Container**: A lightweight, standalone package of software that includes everything needed to run a piece of software.
- **Dependency**: A relationship between workflows where one relies on the completion of another before it can begin.
- **Event**: A trigger that initiates the execution of a pipeline, such as a code push or a manual activation.
- **Forge**: A platform that combines version control system (VCS) functionality with integrated collaboration tools. It typically includes features such as bug tracking, code review, wikis, and project management capabilities. Examples of forges include GitHub, GitLab, and Gitea. Forges provide a centralized environment for software development teams to manage their codebase and coordinate their work.
- **Integration**: The process of combining different subsystems or components to work together as a unified system.
- **Matrix**: A configuration that allows running workflows with different sets of variables or environments.
- **Pipeline**: A defined sequence of automated processes for code to pass through on its way to release. It typically includes building, testing, and deploying code.
- **Plugin**: An extension or add-on that provides pre-defined actions or commands for use in workflows.
- **Repository**: A storage location for code and related files, typically managed by a version control system.
- **Server**: The central component of a CI/CD system that handles webhooks, orchestrates agents, and manages the overall execution of pipelines.
- **Service**: A long-running process that operates alongside a workflow, often providing resources like databases or caching.
- **Status**: The outcome or state of a step, workflow, or pipeline after execution.
- **Step**: An individual task or command within a workflow.
- **Version Control System (VCS)**: A system that tracks changes to files over time, allowing multiple people to collaborate on projects.
- **Webhook**: An HTTP callback that automatically triggers actions in a CI/CD system when certain events occur in a repository.
- **Workflow**: A configurable automated process that is part of a pipeline, usually defined in a YAML file.
- **Workspace**: A directory containing the repository and any generated data, shared between steps in a workflow.
- **YAML File**: A human-readable data serialization format commonly used for configuration files in CI/CD systems.