Merge branch 'main' into graphql

Author: chmouel

.github/workflows/e2e.yaml

@@ -41,7 +41,16 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        provider: [github, github_second_controller, gitlab_bitbucket, gitea_1, gitea_2, gitea_3, concurrency]
+        provider:
+          [
+            github,
+            github_second_controller,
+            gitlab_bitbucket,
+            gitea_1,
+            gitea_2,
+            gitea_3,
+            concurrency,
+          ]
 
     env:
       CONTROLLER_DOMAIN_URL: paac.paac-127-0-0-1.nip.io
@@ -285,7 +294,7 @@ jobs:
       - name: Install minica
         run: |
           go install github.com/jsha/minica@latest
-          echo "$HOME/go/bin" >> $GITHUB_PATH
+          echo "$HOME/go/bin" >> "$GITHUB_PATH"
 
       - name: Clone startpaac
         uses: actions/checkout@v6
@@ -298,6 +307,7 @@ jobs:
           nohup gosmee client --saveDir /tmp/gosmee-replay ${{ secrets.PYSMEE_URL }} "https://${CONTROLLER_DOMAIN_URL}" > /tmp/gosmee-main.log 2>&1 &
 
       - name: Run gosmee for main controller (Gitea)
+        if: startsWith(matrix.provider, 'gitea') || matrix.provider == 'concurrency'
         run: |
           nohup gosmee client --saveDir /tmp/gosmee-replay ${{ secrets.TEST_GITEA_SMEEURL }} "https://${CONTROLLER_DOMAIN_URL}" >> /tmp/gosmee-main.log 2>&1 &
 
@@ -340,6 +350,16 @@ jobs:
           cd startpaac
           ./startpaac --ci -a
 
+      - name: Enable debug logging for e2e
+        run: |
+          set -euo pipefail
+          kubectl -n pipelines-as-code patch configmap pac-config-logging --type merge -p '{"data":{"loglevel.pipelinesascode":"debug","loglevel.pac-watcher":"debug","loglevel.pipelines-as-code-webhook":"debug"}}'
+          kubectl -n pipelines-as-code rollout restart deployment/pipelines-as-code-controller deployment/pipelines-as-code-webhook deployment/pipelines-as-code-watcher
+          for name in controller webhook watcher; do
+            echo "=== Waiting for $name to be ready ==="
+            kubectl -n pipelines-as-code rollout status deployment/pipelines-as-code-$name --timeout=120s
+          done
+
       - name: Install minica CA certificate to system trust store
         run: |
           set -x
@@ -400,7 +420,9 @@ jobs:
           TEST_BITBUCKET_SERVER_API_URL: ${{ secrets.BITBUCKET_SERVER_API_URL }}
           TEST_BITBUCKET_SERVER_WEBHOOK_SECRET: ${{ secrets.BITBUCKET_SERVER_WEBHOOK_SECRET }}
         run: |
-          ./hack/gh-workflow-ci.sh run_e2e_tests
+          mkdir -p /tmp/logs
+          ./hack/gh-workflow-ci.sh run_e2e_tests 2>&1 | tee -a /tmp/logs/e2e-test-output.log
+          exit ${PIPESTATUS[0]}
 
       - name: Collect logs
         if: ${{ always() }}
@@ -410,7 +432,7 @@ jobs:
         run: |
           ./hack/gh-workflow-ci.sh collect_logs
 
-      - name: Show controllers/watcher logs with Snazy
+      - name: Show controllers/watcher errors with Snazy
         if: ${{ always() }}
         run: |
           ./hack/gh-workflow-ci.sh output_logs
@@ -422,11 +444,21 @@ jobs:
           name: logs-e2e-tests-${{ matrix.provider }}
           path: /tmp/logs
 
-      - name: Report Status
-        if: ${{ always() && github.ref_name == 'main' && github.event_name == 'schedule' }}
-        uses: ravsamhq/notify-slack-action@v2
+  notify-slack:
+    name: Notify Slack on Failures
+    runs-on: ubuntu-latest
+    needs: e2e-tests
+    if: ${{ always() && github.ref_name == 'main' && github.event_name == 'schedule' }}
+    steps:
+      - uses: actions/checkout@v6
+      - name: Download all artifacts
+        uses: actions/download-artifact@v4
         with:
-          status: ${{ job.status }}
-          notify_when: "failure"
+          path: artifacts
+          pattern: logs-e2e-tests-*
+
+      - name: Send Slack notification
         env:
           SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
+        run: |
+          ./hack/gh-workflow-ci.sh notify_slack artifacts

Makefile

@@ -16,10 +16,15 @@ SHELL := bash
 TOPDIR := $(shell git rev-parse --show-toplevel)
 TMPDIR := $(TOPDIR)/tmp
 HUGO_BIN := $(TMPDIR)/hugo/hugo
-PY_FILES := $(shell find . -type f -name "*.py" -not -path "./worktrees/*" -not -path "*/.venv/*" -print)
-SH_FILES := $(shell find hack/ -type f -name "*.sh" -not -path "./worktrees/*" -not -path "*/.venv/*" -print)
-YAML_FILES := $(shell find . -type f \( -name "*.yml" -o -name "*.yaml" \) -not -path "./.vale/*" -not -path "./docs/themes/hugo-book/.github/*" -not -path "./worktrees/*" -not -path "./vendor/*" -print)
-MD_FILES := $(shell find . -type f -name "*.md" -not -path "./tmp/*" -not -path "./vendor/*" -not -path "*/.venv/*" -not -path "./.vale/*" -not -path "./docs/themes/*" -not -path "./.git/*" -not -path "./worktrees/*" -print)
+
+# Safe file list helpers using null-delimited output
+# Usage: $(call GIT_LS_FILES,<patterns>,<command>)
+GIT_LS_FILES = git ls-files -z -- $(1) | xargs -0 -r $(2)
+PY_PATTERNS := '*.py' ':!vendor/*'
+SH_PATTERNS := 'hack/*.sh' ':!vendor/*'
+YAML_PATTERNS := '*.yml' '*.yaml' ':!.vale/*' ':!docs/themes/*' ':!vendor/*'
+MD_PATTERNS := '*.md' ':!docs/themes/*' ':!.vale/*' ':!vendor/*'
+MD_YAML_PATTERNS := '*.md' '*.yml' '*.yaml' ':!docs/themes/*' ':!.vale/*' ':!vendor/*' ':!tmp/*'
 
 ifeq ($(PAC_VERSION),)
 	PAC_VERSION="$(shell git describe --tags --exact-match 2>/dev/null || echo nightly-`date +'%Y%m%d'`-`git rev-parse --short HEAD`)"
@@ -89,30 +94,30 @@ lint-go: ## runs go linter on all go files
 							--timeout $(TIMEOUT_UNIT)
 
 .PHONY: lint-yaml
-lint-yaml: ${YAML_FILES} ## runs yamllint on all yaml files
+lint-yaml: ## runs yamllint on all yaml files
 	@echo "Linting yaml files..."
-	@yamllint -c .yamllint $(YAML_FILES)
+	@$(call GIT_LS_FILES,$(YAML_PATTERNS),yamllint -c .yamllint) || true
 
 
 .PHONY: lint-md
 lint-md: ## runs markdownlint and vale on all markdown files
 	@echo "Linting markdown files..."
-	@markdownlint $(MD_FILES)
+	@$(call GIT_LS_FILES,$(MD_PATTERNS),markdownlint) || true
 	@echo "Grammar check with vale of documentation..."
 	@vale docs/content --output=line --glob='*.md'
 	@echo "CodeSpell on docs content"
 	@codespell docs/content
 
 .PHONY: lint-python
-lint-python: ${PY_FILES} ## runs pylint on all python files
+lint-python: ## runs pylint on all python files
 	@echo "Linting python files..."
-	@ruff check $(PY_FILES)
-	@ruff format --check $(PY_FILES)
+	@$(call GIT_LS_FILES,$(PY_PATTERNS),ruff check) || true
+	@$(call GIT_LS_FILES,$(PY_PATTERNS),ruff format --check) || true
 
 .PHONY: lint-shell
-lint-shell: ${SH_FILES} ## runs shellcheck on all python files
+lint-shell: ## runs shellcheck on all shell files
 	@echo "Linting shell script files..."
-	@shellcheck $(SH_FILES)
+	@$(call GIT_LS_FILES,$(SH_PATTERNS),shellcheck) || true
 
 .PHONY: gitlint
 gitlint: ## Run gitlint
@@ -129,19 +134,21 @@ fix-linters: fix-golangci-lint fix-python-errors fix-markdownlint fix-trailing-s
 .PHONY: fix-markdownlint
 fix-markdownlint: ## run markdownlint and fix on all markdown file
 	@echo "Fixing markdown files..."
-	@markdownlint --fix $(MD_FILES)
+	@$(call GIT_LS_FILES,$(MD_PATTERNS),markdownlint --fix) || true
 
 .PHONY: fix-trailing-spaces
 fix-trailing-spaces: ## remove trailing spaces on all markdown and yaml file
-	@sed --in-place 's/[[:space:]]\+$$//' $(MD_FILES) $(YAML_FILES)
-	@[[ -n `git status --porcelain $(MD_FILES) $(YAML_FILES)` ]] && { echo "Markdowns and Yaml files has been cleaned 🧹. Cleaned Files: ";git status --porcelain $(MD_FILES) $(YAML_FILES) ;} || echo "Markdown and YAML are clean ✨"
+	@$(call GIT_LS_FILES,$(MD_YAML_PATTERNS),sed --in-place 's/[[:space:]]\+$$//' --) || true
+	@STATUS=$$(git status --porcelain -- $$(git ls-files -- $(MD_YAML_PATTERNS))) && \
+	[[ -n "$$STATUS" ]] && { echo "Markdowns and Yaml files has been cleaned 🧹. Cleaned Files: "; echo "$$STATUS" ;} || echo "Markdown and YAML are clean ✨"
 
-.PHONE: fix-python-errors
+.PHONY: fix-python-errors
 fix-python-errors: ## fix all python errors generated by ruff
 	@echo "Fixing python files..."
-	@ruff check --fix $(PY_FILES)
-	@ruff format $(PY_FILES)
-	@[[ -n `git status --porcelain $(PY_FILES)` ]] && { echo "Python files has been cleaned 🧹. Cleaned Files: ";git status --porcelain $(PY_FILES) ;} || echo "Python files are clean ✨"
+	@$(call GIT_LS_FILES,$(PY_PATTERNS),ruff check --fix) || true
+	@$(call GIT_LS_FILES,$(PY_PATTERNS),ruff format) || true
+	@STATUS=$$(git status --porcelain -- $$(git ls-files -- $(PY_PATTERNS))) && \
+	[[ -n "$$STATUS" ]] && { echo "Python files has been cleaned 🧹. Cleaned Files: "; echo "$$STATUS" ;} || echo "Python files are clean ✨"
 
 .PHONY: fix-golangci-lint
 fix-golangci-lint: ## run golangci-lint and fix on all go files
@@ -201,5 +208,3 @@ dev-docs: download-hugo ## preview live your docs with hugo
 .PHONY: clean
 clean: ## clean build artifacts
 	rm -fR bin
-
-

README.md

@@ -10,7 +10,7 @@ Pipelines-as-Code is an opinionated CI/CD solution for Tekton and OpenShift Pipe
 
 ## Overview
 
-Pipelines-as-Code brings the [Pipelines-as-Code methodology](https://teamhub.com/blog/understanding-pipeline-as-code-in-software-development/) to Tekton. It provides a simple and declarative way to define your pipelines in your Git repository and have them automatically executed on your Kubernetes cluster. It integrates seamlessly with Git providers like GitHub, GitLab, Bitbucket, and Gitea, and provides feedback directly on your pull requests and commits.
+Pipelines-as-Code brings the [Pipelines-as-Code methodology](https://teamhub.com/blog/understanding-pipeline-as-code-in-software-development/) to Tekton. It provides a simple and declarative way to define your pipelines in your Git repository and have them automatically executed on your Kubernetes cluster. It integrates seamlessly with Git providers like GitHub, GitLab, Bitbucket, and Forgejo, and provides feedback directly on your pull requests and commits.
 
 ## Why Pipelines-as-Code?
 
@@ -54,15 +54,15 @@ Before getting started with Pipelines-as-Code, ensure you have:
 - **Git Provider**: One of:
   - GitHub (GitHub App or Webhook)
   - GitLab (Webhook)
-  - Gitea/Forgejo (Webhook)
+  - Forgejo (Webhook) - Tech Preview
   - Bitbucket Cloud/Data Center (Webhook)
 - **CLI Tool**: `kubectl` for cluster access
 - **Optional**: `tkn` CLI for Tekton operations
 
 ## Key Features
 
 - **Git-based workflow**: Define your Tekton pipelines in your Git repository and have them automatically triggered on Git events like push, pull request, and comments.
-- **Multi-provider support**: Works with GitHub (via GitHub App & Webhook), GitLab, Gitea, Bitbucket Data Center & Cloud via webhooks.
+- **Multi-provider support**: Works with GitHub (via GitHub App & Webhook), GitLab, Forgejo (Tech Preview), Bitbucket Data Center & Cloud via webhooks.
 - **Annotation-driven workflows**: Target specific events, branches, or CEL expressions and gate untrusted PRs with `/ok-to-test` and `OWNERS`; see [Running the PipelineRun](https://pipelinesascode.com/docs/guide/running/).
 - **ChatOps style control**: `/test`, `/retest`, `/cancel`, and branch or tag selectors let you rerun or stop PipelineRuns from PR comments or commit messages; see [GitOps Commands](https://pipelinesascode.com/docs/guide/gitops_commands/).
 - **Skip CI support**: Use `[skip ci]`, `[ci skip]`, `[skip tkn]`, or `[tkn skip]` in commit messages to skip automatic PipelineRun execution for documentation updates or minor changes; GitOps commands can still override and trigger runs manually; see [Skip CI Commands](https://pipelinesascode.com/docs/guide/gitops_commands/#skip-ci-commands).

docs/content/docs/dev/_index.md

@@ -40,55 +40,54 @@ If you need to redeploy just Pipelines as Code, you can use ko directly:
 env KO_DOCKER_REPO=localhost:5000 ko apply -f config -B
 ```
 
-## Gitea
+## Forgejo
 
-Gitea is "unofficially" supported. You just need to configure Gitea the same way
-you do for other webhook methods with a token.
+Forgejo is supported as a Tech Preview provider. See the [Forgejo installation guide](/docs/install/forgejo) for setup instructions.
 
-Here is an example of a Gitea NS/CRD/Secret (set to empty):
+Here is an example of a Forgejo NS/CRD/Secret configuration:
 
 ```yaml
 ---
 apiVersion: v1
 kind: Namespace
 metadata:
-  name: gitea
+  name: forgejo
 
 ---
 apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
 kind: Repository
 metadata:
-  name: gitea
-  namespace: gitea
+  name: forgejo
+  namespace: forgejo
 spec:
-  url: "https://gitea.my.com/owner/repo"
+  url: "https://forgejo.example.com/owner/repo"
   git_provider:
-    user: "git"
-    url: "Your gitea installation URL, i.e: https://gitea.my.com/"
+    type: "gitea"  # Use "gitea" - Forgejo is API-compatible with Gitea
+    url: "https://forgejo.example.com/"
     secret:
-      name: "secret"
+      name: "forgejo-secret"
       key: token
     webhook_secret:
-      name: "secret"
+      name: "forgejo-secret"
       key: "webhook"
 ---
 apiVersion: v1
 kind: Secret
 metadata:
-  name: gitea-home-chmouel
-  namespace: gitea
+  name: forgejo-secret
+  namespace: forgejo
 type: Opaque
 stringData:
-  token: "your token has generated in gitea"
-  webhook: "" # make sure it's empty when you set this up on the interface and here
+  token: "your token generated in Forgejo"
+  webhook: "" # Forgejo allows empty webhook secrets
 ```
 
 There are some gotchas with the webhook validation secret. Pipelines-as-Code
-detects a Gitea install and lets the user set an empty webhook secret (by default
+detects a Forgejo install and lets the user set an empty webhook secret (by default
 it's enforced).
 
-startpaac will by default spin up a new instance of Forgejo (a Gitea fork) to play
-with and run the Gitea E2E tests.
+startpaac will by default spin up a new instance of Forgejo to play
+with and run the Forgejo E2E tests.
 
 You will need to create a Hook URL generated from <https://hook.pipelinesascode.com/new>
 into the environment variable `TEST_GITEA_SMEEURL`.
@@ -104,7 +103,7 @@ The E2E tests will automatically create a repo using the admin username for each
 ## Debugging E2E
 
 As long as you have the secrets set up, you should be able to run the e2e tests properly.
-Gitea is the easiest to run (since they are self-contained). For the rest,
+Forgejo is the easiest to run (since they are self-contained). For the rest,
 you will need to set up some environment variables.
 
 See the [e2e on kind
@@ -268,10 +267,10 @@ This shortcode creates a red warning blockquote indicating that a feature is in
 #### support_matrix
 
 ```markdown
-  { {< support_matrix github_app="true" github_webhook="true|false" gitea="true|false" gitlab="true|false" bitbucket_cloud="true|false" bitbucket_datacenter="true|false" >}}
+  { {< support_matrix github_app="true" github_webhook="true|false" forgejo="true|false" gitlab="true|false" bitbucket_cloud="true|false" bitbucket_datacenter="true|false" >}}
 ```
 
-This shortcode generates a compatibility table showing which Git providers support a particular feature. Each parameter accepts "true" or "false" values, displaying checkmarks (✅) or cross marks (❌) accordingly. The table lists all major Git providers (GitHub App, GitHub Webhook, Gitea, GitLab, Bitbucket Cloud, and Bitbucket Data Center) with their support status for the feature.
+This shortcode generates a compatibility table showing which Git providers support a particular feature. Each parameter accepts "true" or "false" values, displaying checkmarks (✅) or cross marks (❌) accordingly. The table lists all major Git providers (GitHub App, GitHub Webhook, Forgejo, GitLab, Bitbucket Cloud, and Bitbucket Data Center) with their support status for the feature.
 
 ## Documentation when we are doing the Release Process
 

docs/content/docs/guide/gitops_commands.md

@@ -42,7 +42,7 @@ Similar to `/retest`, the `/ok-to-test` command will only trigger new PipelineRu
 ### Requiring a SHA with `/ok-to-test`
 
 {{< tech_preview "Requiring a SHA argument to `/ok-to-test`" >}}
-{{< support_matrix github_app="true" github_webhook="false" gitea="false" gitlab="false" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
+{{< support_matrix github_app="true" github_webhook="false" forgejo="false" gitlab="false" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
 
 Cluster administrators can enforce SHA validation on `/ok-to-test` by setting
 `require-ok-to-test-sha: "true"` in the Pipelines-as-Code ConfigMap. This
@@ -90,7 +90,7 @@ Please be aware that GitOps commands such as `/test` and others will not functio
 
 ## GitOps Commands on Pushed Commits
 
-{{< support_matrix github_app="true" github_webhook="true" gitea="false" gitlab="true" bitbucket_cloud="false" bitbucket_server="false" >}}
+{{< support_matrix github_app="true" github_webhook="true" forgejo="false" gitlab="true" bitbucket_cloud="false" bitbucket_server="false" >}}
 
 If you want to trigger a GitOps command on a pushed commit, you can include the `GitOps` comments within your commit messages. These comments can be used to restart either all pipelines or specific ones. Here's how it works:
 
@@ -168,7 +168,7 @@ The PipelineRun will be restarted regardless of the annotations if the comment `
 
 ### Triggering PipelineRun on Git tags
 
-{{< support_matrix github_app="true" github_webhook="true" gitea="false" gitlab="true" bitbucket_cloud="false" bitbucket_server="false" >}}
+{{< support_matrix github_app="true" github_webhook="true" forgejo="false" gitlab="true" bitbucket_cloud="false" bitbucket_server="false" >}}
 
 You can retrigger a PipelineRun against a specific Git tag by commenting on
 the tagged commit using a GitOps command. Pipelines-as-Code will resolve the

docs/content/docs/guide/matchingevents.md

@@ -189,7 +189,7 @@ files.
 ## Matching a PipelineRun on a Regex in a comment
 
 {{< tech_preview "Matching PipelineRun on regex in comments" >}}
-{{< support_matrix github_app="true" github_webhook="true" gitea="true" gitlab="true" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
+{{< support_matrix github_app="true" github_webhook="true" forgejo="true" gitlab="true" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
 
 You can trigger a PipelineRun based on a comment on a Pull Request or a [Pushed
 Commit]({{< relref
@@ -239,7 +239,7 @@ relref "/docs/guide/gitops_commands.md#gitops-commands-on-pushed-commits" >}}).
 ## Matching PipelineRun to a Pull Request labels
 
 {{< tech_preview "Matching PipelineRun to a Pull-Request label" >}}
-{{< support_matrix github_app="true" github_webhook="true" gitea="true" gitlab="true" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
+{{< support_matrix github_app="true" github_webhook="true" forgejo="true" gitlab="true" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
 
 Using the annotation `pipelinesascode.tekton.dev/on-label`, you can match a
 PipelineRun to a Pull Request label. For example, if you want to match the
@@ -261,7 +261,7 @@ metadata:
   targeted branch.
 * The `on-event` is still needed to match the Pull Request event on the
   proper targeted event.
-* This annotation is currently supported only on GitHub, Gitea, and GitLab
+* This annotation is currently supported only on GitHub, Forgejo, and GitLab
   providers. Bitbucket Cloud and Bitbucket Data Center do not support adding labels
   to Pull Requests.
 * When you add a label to a Pull Request, the corresponding PipelineRun is

docs/content/docs/guide/policy.md

@@ -7,9 +7,9 @@ weight: 50
 
 Pipelines-as-Code uses policies to control which actions can be performed by
 users who belong to specific teams within an organization, as defined on GitHub
-or other supported Git providers (currently GitHub and Gitea).
+or other supported Git providers (currently GitHub and Forgejo).
 
-{{< support_matrix github_app="true" github_webhook="true" gitea="true" gitlab="false" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
+{{< support_matrix github_app="true" github_webhook="true" forgejo="true" gitlab="false" bitbucket_cloud="false" bitbucket_datacenter="false" >}}
 
 ## Supported Actions