Resolve status update issue for GitLab instances with relative paths

[savitaashture]

Issue: https://issues.redhat.com/browse/SRVKP-6899

For GitLab instances hosted under a relative path
(e.g., https://example.servehttp.com/gitlab),
status updates on MR fail to propagate correctly.
Although initial events like Repository CR creation, starting PipelineRuns based on webhooks from GitLab, reporting status on Pipeline start works fine.
subsequent updates (e.g., marking the PipelineRun as Finished) do not reflect in GitLab, leaving the status stuck on Running state.

Though pipelinerun is completed

on GitLab UI it shows running state only

below is the error we got on pac watcher pod

Root Cause:
When we have /gitlab relative path in the API we are getting
the wrong organization info because there is a function which
get Organization and Repository info again from URL

so for a GitLab API https://example.servehttp.com/gitlab/root/testpac
initially Organization and Repository value from GitLab coming
as root and testpac

But later in the event.go file we are refetching Organization and
Repository from event.URL because of that
Organization is coming as gitlab/root and
Repository as testpac.

that's why getting project info api call ex:
(https://example.servehttp.com/gitlab/api/v4/projects/gitlab/root/testpac)
is failing with 404 error

With this PR changes now status is getting updated successfully.

VERIFIED with and without relative path

Changes

Submitter Checklist

• 📝 Please ensure your commit message is clear and informative. For guidance on crafting effective commit messages, refer to the How to write a git commit message guide. We prefer the commit message to be included in the PR body itself rather than a link to an external website (ie: Jira ticket).

• ♽ Before submitting a PR, run make test lint to avoid unnecessary CI processing. For an even more efficient workflow, consider installing pre-commit and running pre-commit install in the root of this repository.

• ✨ We use linters to maintain clean and consistent code. Please ensure you've run make lint before submitting a PR. Some linters offer a --fix mode, which can be executed with the command make fix-linters (ensure markdownlint and golangci-lint tools are installed first).

• 📖 If you're introducing a user-facing feature or changing existing behavior, please ensure it's properly documented.

• 🧪 While 100% coverage isn't a requirement, we encourage unit tests for any code changes where possible.

• 🎁 If feasible, please check if an end-to-end test can be added. See README for more details.

• 🔎 If there's any flakiness in the CI tests, don't necessarily ignore it. It's better to address the issue before merging, or provide a valid reason to bypass it if fixing isn't possible (e.g., token rate limitations).

• If you are adding a provider feature, please fill up the following details which provider this feature supports:

  • GitHub
  • GitHub Webhook
  • Gitea
  • Gitlab
  • Bitbucket Cloud
  • Bitbucket Server/DC

  (make sure to update the documentation accordingly)

[chmouel]

The sourceProjectID and targetProjectID in the event object were being reset to for GitLab instances with relative paths, causing API requests to GitLab

Regarding the reset of the sourceProjectId and targetProjectID, would you know the potential causes so we can identify the point of origin? I am interested in understanding if this issue might manifest under different circumstances or
scenarios.

[savitaashture]

Regarding the reset of the sourceProjectId and targetProjectID, would you know the potential causes so we can identify the point of origin? I am interested in understanding if this issue might manifest under different circumstances or
scenarios.

Yes the given root cause in the description is not right

actually with and without path (/gitlab) the sourceProjectId and targetProjectID is 0 that's where we have this if condition https://github.com/openshift-pipelines/pipelines-as-code/blob/main/pkg/provider/gitlab/gitlab.go#L144-L156 to get that data from GitLab back

But when we have /gitlab in the API we are getting the wrong org info because this function https://github.com/openshift-pipelines/pipelines-as-code/blob/main/pkg/reconciler/event.go#L65 overrides the org value

so for a GitLab API https://paladugu.servehttp.com/gitlab/root/testpac
initially org and repo value from gitlab coming as root and testpac

But later in the event.go file we are refetching org and repo from repo.URL because of that
Org is : gitlab/root
repo is: testpac

that's why this call https://github.com/openshift-pipelines/pipelines-as-code/blob/main/pkg/provider/gitlab/gitlab.go#L146 is failing with 404 which is valid

Fix is

1. Either I need to modify https://github.com/openshift-pipelines/pipelines-as-code/blob/main/pkg/reconciler/event.go#L65 function such a way that it gets correct org and repo info

2. I can make use of below annotation directly

    pipelinesascode.tekton.dev/url-org: root
    pipelinesascode.tekton.dev/url-repository: testpac

instead of getting data from event.URL