Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(gitea): use configured endpoint in PR cache #33121

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

javiertury
Copy link

Changes

Ensure that gitea PR cache uses the endpoint configured by the user

Context

As detailed in issue #32825, renovate paginates using the url returned by gitea, which may change the endpoint. This causes authentication failures since tokens are not attached to the request or a network error if the returned url is not accesible from within the network. Also a gitea instance configured with a http public url would remove transport encryption even if renovate was configured with a https endpoint.

Documentation (please check one with an [x])

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests but ran on a real repository, or
  • Both unit tests + ran on a real repository

@viceice viceice changed the title fix(gitea): use configured endpoint in PR cache (#32825) fix(gitea): use configured endpoint in PR cache Dec 15, 2024
Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

implement RENOVATE_X_REBASE_PAGINATION_LINKS like GitHub

!!process.env.RENOVATE_X_REBASE_PAGINATION_LINKS &&

@javiertury
Copy link
Author

What is the advantage of RENOVATE_X_REBASE_PAGINATION_LINKS over the proposed solution? We can address the root of the problem if we eliminate the need to rebase in the first place.

According to gitea docs, the pulls endpoint works with limit-offset pagination and next.url just increases the page counter so both methods are equivalent. It is not the case that next.url uses stateless cursor pagination or something more performant, and even if it was the case my guess is that gitea would provide a well-designed API such that we can pass the cursor through query parameters.

@viceice
Copy link
Member

viceice commented Dec 15, 2024

we did the decision some time ago, there where more discussions about it. so please do it like we suggest.

@viceice viceice marked this pull request as draft December 17, 2024 08:36
@viceice
Copy link
Member

viceice commented Dec 17, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants