Story (Required)

As a Pipelines as Code developer/contributor, trying to ensure the reliability
and consistency of PaC CI and support modern Git providers, I want `Pipelines-as-Code CI` to
leverage `startpaac` for its execution environment and for PaC to support
Forgejo.

This story aims to improve the developer experience for PaC contributors by aligning the CI environment (`pac ci`) with the local testing environment (`startpaac`), reducing unexpected CI failures. It also addresses the need to support Forgejo, an increasingly popular Gitea fork, ensuring PaC remains compatible with relevant Git hosting platforms.

Background (Required)

*Currently, the `pac ci` command used for testing Pipelines as Code itself
sometimes produces unexpected or "weird" errors. It uses some custom scripts
spining up gitea.

Local development and testing often utilize the `startpaac` tool
(<https://github.com/chmouel/startpaac/>) which provides a consistent
environment. This discrepancy between CI and local setups can lead to
difficult-to-diagnose issues.*

*Furthermore, the Git hosting landscape is evolving. Forgejo, a fork of Gitea,
is gaining traction (e.g., Fedora's planned migration). There have been
requests for Konflux/PaC integration with Forgejo. To ensure future
compatibility and meet user needs, PaC needs to explicitly support Forgejo as a
Git provider.*

*Integrating `startpaac` into `pac ci` aims to create consistency and improve
CI stability. Supporting Forgejo prepares PaC for upcoming ecosystem shifts and
integration demands.*

Out of scope

• Replacing the underlying CI platform itself.
• Adding support for other new Git providers beyond Forgejo in this specific
  story.
• A full audit and fix of all potential PaC bugs unrelated to the CI
  environment consistency or Forgejo integration.
• Immediate removal or deprecation date for Gitea support (though Forgejo
  support might eventually supersede it functionally).

Approach (Required)

• *Integrate `startpaac` into `pac ci`:*
• Modify the `pac ci` command logic to utilize `startpaac` for setting up the test environment and executing the PaC test suite.
• Ensure necessary parameters and configurations are passed correctly to `startpaac`.
• *(Optional but Recommended) Relocate `startpaac`:*
• Evaluate and potentially execute the migration of the `startpaac` repository from `chmouel/startpaac` to the `openshift-pipelines` GitHub organization for better visibility, maintenance, and alignment.
• Update any internal references or dependencies if the repo is moved.
  creation/management, status reporting, and other relevant interactions.
• Include automated tests in the PaC CI specifically targeting a Forgejo instance.

Dependencies

• Availability and stability of the `startpaac` tool.
• Access to a running Forgejo instance for development and testing purposes.
• (If moving `startpaac`) Organizational approval/process for repository migration to `openshift-pipelines`.

Acceptance Criteria (Mandatory)

• Running `pac ci` successfully executes the PaC test suite within an environment provisioned by `startpaac`.
• The main PaC CI pipeline runs successfully using the modified `pac ci` command.
• CI results show improved consistency compared to previous runs, with fewer environment-related "weird" errors.
• PaC commands and functionalities (e.g., webhook registration, status reporting) work correctly with a Forgejo repository.
• Automated tests exist and pass in CI, validating core PaC functionality against a Forgejo instance.
• (If `startpaac` is moved) The `pac ci` integration correctly uses `startpaac` from its new location in the `openshift-pipelines` organization.

INVEST Checklist

➖ Dependencies identified
➖ Blockers noted and expected delivery timelines set
➖ Design is implementable
➖ Acceptance criteria agreed upon
➖ Story estimated

Legend

➖ Unknown
✅ Verified
❌ Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly
  in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met