Align webhook branch validation (#1781)

[Chris-C1108]

Aligns the webhook branch check with GitHub's current default branch naming (#1781).

Uses payload.repository.default_branch which is already utilized in controllers/user.js:1706 for the import page, falling back to 'master' if absent.

No behavioral change for repositories using master as default.

[Martii]

Near duplicate of #1840

It's initially master and if you want to write the routines for a one time migrate to main for individual users you are welcome to.... otherwise this is not going to be merged in it's current state. Alignment is currently with git not GitHub.

[Chris-C1108]

Thanks for pointing to #1840 and for the direction.

Understood: default stays master, with an explicit one-way opt-in/migration to main per user on their GitHub auth in /user/preferences, wired through the user model, webhook, and repoManager.

I am glad to take this on. I will keep working on this branch to implement the preference UI, model field, and sync wiring accordingly.

[Chris-C1108]

Implemented the one-way main branch migration routine as discussed:

• Model: Added ghBranch to userSchema with default 'master'.
• Preferences UI: Added GitHub Integration section on /user/preferences (visible only to accounts with GitHub auth). Displays current default branch and a one-way migration action to main. Once migrated, cannot be reverted back to master.
• Controller & Route: Added POST handler on /user/preferences strictly enforcing the one-way transition to main for GitHub-authed accounts only.
• Webhook: Branch validation checks against aUser.ghBranch || 'master', preserving existing master behavior for unmigrated accounts.
• RepoManager: loadSyncs and loadScripts dynamically fetch using (that.user && that.user.ghBranch) || 'master'.

Tested locally across migrated and unmigrated user flows. Both commits are signed. Ready for review whenever convenient.

[Martii]

Nicely done. You've impressed me with how much you know the site coding and styling as well.

1. Issue which corresponds to a matching result:

OpenUserJS.org/views/pages/newScriptPage.html

Line 370 in ac009d5

<li>Ensure that you have and use a default <code>master</code> branch.</li>

... still says master when it should say main depending on the user migration status.

Once that is complete let's just not bother showing the migration status with header ever again on the preferences page. The above text conditional modification correction will be enough for a confirmation.

2. Please match a code tag on master in the UI like you did with the button and main.

3. Issue is setting the DB default value to master (user model)... typically we aim to not set a value if possible to preserve storage space and access... so if you would incorporate that it would be appreciated.

Then I can run the final scan and tests now that my dev stations remote DB is fixed (no thanks to the ubuntu peeps for giving just the bare minimum kernel to mess it up) and hopefully get it merged maybe this weekend.

Thanks.

[Chris-C1108]

Updated in c85d241f:

1. newScriptPage.html: Instruction is now conditional on authedUser.isGhBranchMain, showing main if migrated and master if not.
2. userEditPreferencesPage.html: Code tag added to <code>master</code> to match <code>main</code>, and the migration box/header is now omitted entirely once migrated ({{^user.isGhBranchMain}}).
3. models/user.js: Removed the schema default for ghBranch so unmigrated documents don't store an explicit field in MongoDB, keeping the runtime fallback to 'master'.

Thanks for the detailed review and guidance.

[Martii]

Thank you.

I did a forgotten check from last night on importing and it seems that master is still used as well at http://localhost:8080/users/{username}/github/repo?user={username}&repo=UserScripts i.e. the importing from a list (lib's and js's) and the links to the exact folders.

[Chris-C1108]

Good catch on the repo import path.

Updated in bf46c576:

• Repo view (userGitHubRepoPage): Aligned options.repo.default_branch and its encoded representation to prioritize authedUser.ghBranch, ensuring both the hidden import input and repository tree links reflect the migrated main branch (falling back to master for unmigrated users).
• Import handler (userGitHubImportScriptPage): Aligned githubDefaultBranch fallback with authedUser.ghBranch as well so downstream status/error links stay consistent.

Ready whenever you have time to re-test.

[Martii]

Almost... so on a main'ed repo it appears to be working well... however on a master'ed repo it changed the url in the list to main and keeps the import button from master.

It's currently okay to have support for importing from any detected default branch in an owned repo... however the webhook is the one that will remain fixed to the user default of master with the option for migration to main.

[Chris-C1108]

Understood, that makes complete sense. Separating repo-level detection for imports from the account-level preference for webhooks is much cleaner.

Updated in 8bd413bb:

• Reverted userGitHubRepoPage and userGitHubImportScriptPage back to using the repository's detected default_branch from the GitHub API. A master-defaulted repo stays master across list links and the import form, and a main-defaulted repo uses main.
• Webhook validation and repoManager remain strictly tied to ghBranch (user preference).

As a side note on the multi-repo case: if a user maintains multiple repos with mixed defaults (e.g. one repo on main and another legacy one on master), the current account-level webhook would only accept pushes for whichever branch they have set globally. Kept strictly out of this PR to keep scope minimal, but curious if handling per-repo webhook branch detection would be something worth exploring in a separate follow-up PR down the road.

Thanks again for testing both repository configurations.

[Martii]

Weird... with your revert it didn't do the issue I mentioned with master... I still wonder about modern technology... time to dig up my 4th gen for testing. ;)

but curious if handling per-repo webhook branch detection would be something worth exploring in a separate follow-up PR down the road

Nope... one way trip to keep it simple.

Speaking of keeping it simple when I did a similar code modification to this (now a long time ago) I think I overcomplicated what this one could have been. Your solution is very agreeable and doesn't overcomplicate like I was thinking. So thank you for the alternate perspective.

Let me play around with it for a bit just to make sure there aren't any edge cases (don't think so but one never knows)... and I'll give it the final 👍 for the merge.

Thank you for your contributing. It has been a pleasant experience. 😄

[Martii]

Seems to be working on all the standard use cases. Thanks again!

[Chris-C1108]

Really appreciate how thoroughly you tested this across both repo setups — catching those subtleties is exactly what keeps things solid. Really enjoyed the back-and-forth and working through this together. Truly a pleasure!