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.

Sign up for GitHub

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

Jump to bottom

Refactor forkMode to use git fetching #13586

Open
rarkins opened this issue Jan 17, 2022 · 4 comments · Fixed by #13808 · May be fixed by #34467
Open

Refactor forkMode to use git fetching #13586

rarkins opened this issue Jan 17, 2022 · 4 comments · Fixed by #13808 · May be fixed by #34467
Labels
platform:github GitHub Platform priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:refactor Refactoring or improving of existing code

Comments

@rarkins
Copy link
Collaborator

rarkins commented Jan 17, 2022

Describe the proposed change(s).

Today forkMode is supported only for GitHub, and nearly 100% of code is within https://github.com/renovatebot/renovate/blob/main/lib/platform/github/index.ts

I would like to refactor it to improve the functionality with GitHub and also add the possibility for other platform support.

Use upstream terminology

Today we have the term parentRepo. Let's use the term upstream instead, to align with GitHub's terminology.

Perform upstream fetching using git

Today we use this API call:

renovate/lib/platform/github/index.ts

Lines 425 to 439 in 9f7d024

// This is a lovely "hack" by GitHub that lets us force update our fork's default branch
// with the base commit from the parent repository
const url = `repos/${config.repository}/git/refs/heads/${config.defaultBranch}`;
const sha = repo.defaultBranchRef.target.oid;
try {
logger.debug(
`Updating forked repository default sha ${sha} to match upstream`
);
await githubApi.patchJson(url, {
body: {
sha,
force: true,
},
token: forkToken || opts.token,
});

But with our git layer, we should instead use that to fetch instead, by making our git "upstream aware". Doing so would also mean we can more easily support baseBranches, which is unsupported today for forkMode. Within git we should refer to that upstream/parent as upstream and "fetch from upstream". This can possibly be done in phases, such as using git to sync upstream default branch only initially before expanding it to support baseBranches.
@rarkins rarkins added priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:refactor Refactoring or improving of existing code status:ready labels Jan 17, 2022
@rarkins rarkins self-assigned this Jan 25, 2022
rarkins added a commit that referenced this issue Jan 25, 2022
@rarkins
feat(git): use git fetching for forkMode
e45cb71 
Closes #13586
rarkins added a commit that referenced this issue Jan 25, 2022
@rarkins
feat(git): sync default branch with upstream using git
74d4676 
Closes #13586
@rarkins rarkins mentioned this issue Jan 25, 2022
Merged
6 tasks
@renovate-release

This comment was marked as outdated.

Sign in to view
@rarkins rarkins reopened this Feb 16, 2022
@simonbasle
Copy link

I see this issue is marked as in-progress. any update on this? even as a MVP where only a single baseBranch is supported?

currently we're caught between a rock and a hard place, as if I change my repo's default branch to be the "oldest" maintenance branch activately maintained, then other parts of our workflow fall apart (eg. GitHub will stop closing issues that get a commit in our "newest" maintenance branch via commit messages, because it only considers the default branch for that).

I also wonder if manually changing the target branch by editing the Renovate PR would be a viable workaround?

@rarkins
Copy link
Collaborator Author

rarkins commented Mar 9, 2022

It was released and then reverted, because the original problem was found to be due to token permissions and the implementation was an it hacky. Therefore it is not currently in progress, but someone could might make quick work of it if they take the original PR.

If you edit the target branch then Renovate will cease updating the PR unless you manually request a rebase.

@simonbasle
Copy link

Editing the target branch doesn't work because the PR now includes newest commits in the main branch :( Even after asking Renovate to rebase. So I effectively have to edit every single PR created by Renovate in two ways: A) edit the PR target branch and B) locally check it out, rebase and drop extraneous commits and force push.

But maybe a new GitHub API can be used during fork synchronization, see my comment in #7850.

@rarkins rarkins mentioned this issue May 9, 2023
Open
@rarkins rarkins removed their assignment Jun 27, 2023
@rarkins rarkins mentioned this issue Jan 24, 2025
Open
@janhoy janhoy linked a pull request Feb 26, 2025 that will close this issue
Draft
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
platform:github GitHub Platform priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:refactor Refactoring or improving of existing code
Projects
None yet
Milestone
No milestone
3 participants
@rarkins @simonbasle @renovate-release