1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-12-29 13:59:15 -05:00
forgejo/services/wiki/wiki.go

426 lines
12 KiB
Go
Raw Normal View History

// Copyright 2015 The Gogs Authors. All rights reserved.
// Copyright 2019 The Gitea Authors. All rights reserved.
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
// Copyright 2024 The Forgejo Authors c/o Codeberg e.V.. All rights reserved.
// SPDX-License-Identifier: MIT
package wiki
import (
"context"
"fmt"
"os"
"strings"
repo_model "code.gitea.io/gitea/models/repo"
system_model "code.gitea.io/gitea/models/system"
"code.gitea.io/gitea/models/unit"
user_model "code.gitea.io/gitea/models/user"
"code.gitea.io/gitea/modules/git"
"code.gitea.io/gitea/modules/gitrepo"
"code.gitea.io/gitea/modules/log"
repo_module "code.gitea.io/gitea/modules/repository"
"code.gitea.io/gitea/modules/sync"
asymkey_service "code.gitea.io/gitea/services/asymkey"
repo_service "code.gitea.io/gitea/services/repository"
)
// TODO: use clustered lock (unique queue? or *abuse* cache)
var wikiWorkingPool = sync.NewExclusivePool()
const (
DefaultRemote = "origin"
)
// InitWiki initializes a wiki for repository,
// it does nothing when repository already has wiki.
func InitWiki(ctx context.Context, repo *repo_model.Repository) error {
if repo.HasWiki() {
return nil
}
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
branch := repo.GetWikiBranchName()
if err := git.InitRepository(ctx, repo.WikiPath(), true, repo.ObjectFormatName); err != nil {
return fmt.Errorf("InitRepository: %w", err)
} else if err = repo_module.CreateDelegateHooks(repo.WikiPath()); err != nil {
return fmt.Errorf("createDelegateHooks: %w", err)
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
} else if _, _, err = git.NewCommand(ctx, "symbolic-ref", "HEAD").AddDynamicArguments(git.BranchPrefix + branch).RunStdString(&git.RunOpts{Dir: repo.WikiPath()}); err != nil {
return fmt.Errorf("unable to set default wiki branch to %s: %w", branch, err)
}
return nil
}
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
// NormalizeWikiBranch renames a repository wiki's branch to `setting.Repository.DefaultBranch`
func NormalizeWikiBranch(ctx context.Context, repo *repo_model.Repository, to string) error {
from := repo.GetWikiBranchName()
if err := repo.MustNotBeArchived(); err != nil {
return err
}
updateDB := func() error {
repo.WikiBranch = to
return repo_model.UpdateRepositoryCols(ctx, repo, "wiki_branch")
}
if !repo.HasWiki() {
return updateDB()
}
if from == to {
return nil
}
gitRepo, err := git.OpenRepository(ctx, repo.WikiPath())
if err != nil {
return err
}
defer gitRepo.Close()
if gitRepo.IsBranchExist(to) {
return nil
}
if !gitRepo.IsBranchExist(from) {
return nil
}
if err := gitRepo.RenameBranch(from, to); err != nil {
return err
}
if err := gitrepo.SetDefaultBranch(ctx, repo, to); err != nil {
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
return err
}
return updateDB()
}
// prepareGitPath try to find a suitable file path with file name by the given raw wiki name.
// return: existence, prepared file path with name, error
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
func prepareGitPath(gitRepo *git.Repository, branch string, wikiPath WebPath) (bool, string, error) {
unescaped := string(wikiPath) + ".md"
gitPath := WebPathToGitPath(wikiPath)
// Look for both files
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
filesInIndex, err := gitRepo.LsTree(branch, unescaped, gitPath)
if err != nil {
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
if strings.Contains(err.Error(), "Not a valid object name "+branch) {
return false, gitPath, nil
}
log.Error("%v", err)
return false, gitPath, err
}
foundEscaped := false
for _, filename := range filesInIndex {
switch filename {
case unescaped:
// if we find the unescaped file return it
return true, unescaped, nil
case gitPath:
foundEscaped = true
}
}
// If not return whether the escaped file exists, and the escaped filename to keep backwards compatibility.
return foundEscaped, gitPath, nil
}
Webhook for Wiki changes (#20219) Add support for triggering webhook notifications on wiki changes. This PR contains frontend and backend for webhook notifications on wiki actions (create a new page, rename a page, edit a page and delete a page). The frontend got a new checkbox under the Custom Event -> Repository Events section. There is only one checkbox for create/edit/rename/delete actions, because it makes no sense to separate it and others like releases or packages follow the same schema. ![image](https://user-images.githubusercontent.com/121972/177018803-26851196-831f-4fde-9a4c-9e639b0e0d6b.png) The actions itself are separated, so that different notifications will be executed (with the "action" field). All the webhook receivers implement the new interface method (Wiki) and the corresponding tests. When implementing this, I encounter a little bug on editing a wiki page. Creating and editing a wiki page is technically the same action and will be handled by the ```updateWikiPage``` function. But the function need to know if it is a new wiki page or just a change. This distinction is done by the ```action``` parameter, but this will not be sent by the frontend (on form submit). This PR will fix this by adding the ```action``` parameter with the values ```_new``` or ```_edit```, which will be used by the ```updateWikiPage``` function. I've done integration tests with matrix and gitea (http). ![image](https://user-images.githubusercontent.com/121972/177018795-eb5cdc01-9ba3-483e-a6b7-ed0e313a71fb.png) Fix #16457 Signed-off-by: Aaron Fischer <mail@aaron-fischer.net>
2022-09-04 15:54:23 -04:00
// updateWikiPage adds a new page or edits an existing page in repository wiki.
func updateWikiPage(ctx context.Context, doer *user_model.User, repo *repo_model.Repository, oldWikiName, newWikiName WebPath, content, message string, isNew bool) (err error) {
err = repo.MustNotBeArchived()
if err != nil {
return err
}
if err = validateWebPath(newWikiName); err != nil {
return err
}
wikiWorkingPool.CheckIn(fmt.Sprint(repo.ID))
defer wikiWorkingPool.CheckOut(fmt.Sprint(repo.ID))
if err = InitWiki(ctx, repo); err != nil {
return fmt.Errorf("InitWiki: %w", err)
}
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
hasMasterBranch := git.IsBranchExist(ctx, repo.WikiPath(), repo.GetWikiBranchName())
basePath, err := repo_module.CreateTemporaryPath("update-wiki")
if err != nil {
return err
}
defer func() {
if err := repo_module.RemoveTemporaryPath(basePath); err != nil {
log.Error("Merge: RemoveTemporaryPath: %s", err)
}
}()
cloneOpts := git.CloneRepoOptions{
Bare: true,
Shared: true,
}
if hasMasterBranch {
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
cloneOpts.Branch = repo.GetWikiBranchName()
}
if err := git.Clone(ctx, repo.WikiPath(), basePath, cloneOpts); err != nil {
log.Error("Failed to clone repository: %s (%v)", repo.FullName(), err)
return fmt.Errorf("failed to clone repository: %s (%w)", repo.FullName(), err)
}
gitRepo, err := git.OpenRepository(ctx, basePath)
if err != nil {
log.Error("Unable to open temporary repository: %s (%v)", basePath, err)
return fmt.Errorf("failed to open new temporary repository in: %s %w", basePath, err)
}
defer gitRepo.Close()
if hasMasterBranch {
if err := gitRepo.ReadTreeToIndex("HEAD"); err != nil {
log.Error("Unable to read HEAD tree to index in: %s %v", basePath, err)
return fmt.Errorf("fnable to read HEAD tree to index in: %s %w", basePath, err)
}
}
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
isWikiExist, newWikiPath, err := prepareGitPath(gitRepo, repo.GetWikiBranchName(), newWikiName)
if err != nil {
return err
}
if isNew {
if isWikiExist {
return repo_model.ErrWikiAlreadyExist{
Title: newWikiPath,
}
}
} else {
// avoid check existence again if wiki name is not changed since gitRepo.LsFiles(...) is not free.
isOldWikiExist := true
oldWikiPath := newWikiPath
if oldWikiName != newWikiName {
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
isOldWikiExist, oldWikiPath, err = prepareGitPath(gitRepo, repo.GetWikiBranchName(), oldWikiName)
if err != nil {
return err
}
}
if isOldWikiExist {
err := gitRepo.RemoveFilesFromIndex(oldWikiPath)
if err != nil {
log.Error("RemoveFilesFromIndex failed: %v", err)
return err
}
}
}
// FIXME: The wiki doesn't have lfs support at present - if this changes need to check attributes here
objectHash, err := gitRepo.HashObject(strings.NewReader(content))
if err != nil {
log.Error("HashObject failed: %v", err)
return err
}
if err := gitRepo.AddObjectToIndex("100644", objectHash, newWikiPath); err != nil {
log.Error("AddObjectToIndex failed: %v", err)
return err
}
tree, err := gitRepo.WriteTree()
if err != nil {
log.Error("WriteTree failed: %v", err)
return err
}
commitTreeOpts := git.CommitTreeOpts{
Message: message,
}
Add configurable Trust Models (#11712) * Add configurable Trust Models Gitea's default signature verification model differs from GitHub. GitHub uses signatures to verify that the committer is who they say they are - meaning that when GitHub makes a signed commit it must be the committer. The GitHub model prevents re-publishing of commits after revocation of a key and prevents re-signing of other people's commits to create a completely trusted repository signed by one key or a set of trusted keys. The default behaviour of Gitea in contrast is to always display the avatar and information related to a signature. This allows signatures to be decoupled from the committer. That being said, allowing arbitary users to present other peoples commits as theirs is not necessarily desired therefore we have a trust model whereby signatures from collaborators are marked trusted, signatures matching the commit line are marked untrusted and signatures that match a user in the db but not the committer line are marked unmatched. The problem with this model is that this conflicts with Github therefore we need to provide an option to allow users to choose the Github model should they wish to. Signed-off-by: Andrew Thornton <art27@cantab.net> * Adjust locale strings Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @6543 Co-authored-by: 6543 <6543@obermui.de> * Update models/gpg_key.go * Add migration for repository Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-19 12:44:55 -04:00
committer := doer.NewGitSig()
sign, signingKey, signer, _ := asymkey_service.SignWikiCommit(ctx, repo, doer)
if sign {
commitTreeOpts.KeyID = signingKey
if repo.GetTrustModel() == repo_model.CommitterTrustModel || repo.GetTrustModel() == repo_model.CollaboratorCommitterTrustModel {
Add configurable Trust Models (#11712) * Add configurable Trust Models Gitea's default signature verification model differs from GitHub. GitHub uses signatures to verify that the committer is who they say they are - meaning that when GitHub makes a signed commit it must be the committer. The GitHub model prevents re-publishing of commits after revocation of a key and prevents re-signing of other people's commits to create a completely trusted repository signed by one key or a set of trusted keys. The default behaviour of Gitea in contrast is to always display the avatar and information related to a signature. This allows signatures to be decoupled from the committer. That being said, allowing arbitary users to present other peoples commits as theirs is not necessarily desired therefore we have a trust model whereby signatures from collaborators are marked trusted, signatures matching the commit line are marked untrusted and signatures that match a user in the db but not the committer line are marked unmatched. The problem with this model is that this conflicts with Github therefore we need to provide an option to allow users to choose the Github model should they wish to. Signed-off-by: Andrew Thornton <art27@cantab.net> * Adjust locale strings Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @6543 Co-authored-by: 6543 <6543@obermui.de> * Update models/gpg_key.go * Add migration for repository Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-19 12:44:55 -04:00
committer = signer
}
} else {
commitTreeOpts.NoGPGSign = true
}
if hasMasterBranch {
commitTreeOpts.Parents = []string{"HEAD"}
}
Add configurable Trust Models (#11712) * Add configurable Trust Models Gitea's default signature verification model differs from GitHub. GitHub uses signatures to verify that the committer is who they say they are - meaning that when GitHub makes a signed commit it must be the committer. The GitHub model prevents re-publishing of commits after revocation of a key and prevents re-signing of other people's commits to create a completely trusted repository signed by one key or a set of trusted keys. The default behaviour of Gitea in contrast is to always display the avatar and information related to a signature. This allows signatures to be decoupled from the committer. That being said, allowing arbitary users to present other peoples commits as theirs is not necessarily desired therefore we have a trust model whereby signatures from collaborators are marked trusted, signatures matching the commit line are marked untrusted and signatures that match a user in the db but not the committer line are marked unmatched. The problem with this model is that this conflicts with Github therefore we need to provide an option to allow users to choose the Github model should they wish to. Signed-off-by: Andrew Thornton <art27@cantab.net> * Adjust locale strings Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @6543 Co-authored-by: 6543 <6543@obermui.de> * Update models/gpg_key.go * Add migration for repository Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-19 12:44:55 -04:00
commitHash, err := gitRepo.CommitTree(doer.NewGitSig(), committer, tree, commitTreeOpts)
if err != nil {
log.Error("CommitTree failed: %v", err)
return err
}
if err := git.Push(gitRepo.Ctx, basePath, git.PushOptions{
Remote: DefaultRemote,
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
Branch: fmt.Sprintf("%s:%s%s", commitHash.String(), git.BranchPrefix, repo.GetWikiBranchName()),
Env: repo_module.FullPushingEnvironment(
doer,
doer,
repo,
repo.Name+".wiki",
0,
),
}); err != nil {
log.Error("Push failed: %v", err)
if git.IsErrPushOutOfDate(err) || git.IsErrPushRejected(err) {
return err
}
return fmt.Errorf("failed to push: %w", err)
}
return nil
}
// AddWikiPage adds a new wiki page with a given wikiPath.
func AddWikiPage(ctx context.Context, doer *user_model.User, repo *repo_model.Repository, wikiName WebPath, content, message string) error {
return updateWikiPage(ctx, doer, repo, "", wikiName, content, message, true)
}
// EditWikiPage updates a wiki page identified by its wikiPath,
// optionally also changing wikiPath.
func EditWikiPage(ctx context.Context, doer *user_model.User, repo *repo_model.Repository, oldWikiName, newWikiName WebPath, content, message string) error {
return updateWikiPage(ctx, doer, repo, oldWikiName, newWikiName, content, message, false)
}
// DeleteWikiPage deletes a wiki page identified by its path.
func DeleteWikiPage(ctx context.Context, doer *user_model.User, repo *repo_model.Repository, wikiName WebPath) (err error) {
err = repo.MustNotBeArchived()
if err != nil {
return err
}
wikiWorkingPool.CheckIn(fmt.Sprint(repo.ID))
defer wikiWorkingPool.CheckOut(fmt.Sprint(repo.ID))
if err = InitWiki(ctx, repo); err != nil {
return fmt.Errorf("InitWiki: %w", err)
}
basePath, err := repo_module.CreateTemporaryPath("update-wiki")
if err != nil {
return err
}
defer func() {
if err := repo_module.RemoveTemporaryPath(basePath); err != nil {
log.Error("Merge: RemoveTemporaryPath: %s", err)
}
}()
if err := git.Clone(ctx, repo.WikiPath(), basePath, git.CloneRepoOptions{
Bare: true,
Shared: true,
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
Branch: repo.GetWikiBranchName(),
}); err != nil {
log.Error("Failed to clone repository: %s (%v)", repo.FullName(), err)
return fmt.Errorf("failed to clone repository: %s (%w)", repo.FullName(), err)
}
gitRepo, err := git.OpenRepository(ctx, basePath)
if err != nil {
log.Error("Unable to open temporary repository: %s (%v)", basePath, err)
return fmt.Errorf("failed to open new temporary repository in: %s %w", basePath, err)
}
defer gitRepo.Close()
if err := gitRepo.ReadTreeToIndex("HEAD"); err != nil {
log.Error("Unable to read HEAD tree to index in: %s %v", basePath, err)
return fmt.Errorf("unable to read HEAD tree to index in: %s %w", basePath, err)
}
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
found, wikiPath, err := prepareGitPath(gitRepo, repo.GetWikiBranchName(), wikiName)
if err != nil {
return err
}
if found {
err := gitRepo.RemoveFilesFromIndex(wikiPath)
if err != nil {
return err
}
} else {
return os.ErrNotExist
}
// FIXME: The wiki doesn't have lfs support at present - if this changes need to check attributes here
tree, err := gitRepo.WriteTree()
if err != nil {
return err
}
message := fmt.Sprintf("Delete page %q", wikiName)
commitTreeOpts := git.CommitTreeOpts{
Message: message,
Parents: []string{"HEAD"},
}
Add configurable Trust Models (#11712) * Add configurable Trust Models Gitea's default signature verification model differs from GitHub. GitHub uses signatures to verify that the committer is who they say they are - meaning that when GitHub makes a signed commit it must be the committer. The GitHub model prevents re-publishing of commits after revocation of a key and prevents re-signing of other people's commits to create a completely trusted repository signed by one key or a set of trusted keys. The default behaviour of Gitea in contrast is to always display the avatar and information related to a signature. This allows signatures to be decoupled from the committer. That being said, allowing arbitary users to present other peoples commits as theirs is not necessarily desired therefore we have a trust model whereby signatures from collaborators are marked trusted, signatures matching the commit line are marked untrusted and signatures that match a user in the db but not the committer line are marked unmatched. The problem with this model is that this conflicts with Github therefore we need to provide an option to allow users to choose the Github model should they wish to. Signed-off-by: Andrew Thornton <art27@cantab.net> * Adjust locale strings Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @6543 Co-authored-by: 6543 <6543@obermui.de> * Update models/gpg_key.go * Add migration for repository Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-19 12:44:55 -04:00
committer := doer.NewGitSig()
sign, signingKey, signer, _ := asymkey_service.SignWikiCommit(ctx, repo, doer)
if sign {
commitTreeOpts.KeyID = signingKey
if repo.GetTrustModel() == repo_model.CommitterTrustModel || repo.GetTrustModel() == repo_model.CollaboratorCommitterTrustModel {
Add configurable Trust Models (#11712) * Add configurable Trust Models Gitea's default signature verification model differs from GitHub. GitHub uses signatures to verify that the committer is who they say they are - meaning that when GitHub makes a signed commit it must be the committer. The GitHub model prevents re-publishing of commits after revocation of a key and prevents re-signing of other people's commits to create a completely trusted repository signed by one key or a set of trusted keys. The default behaviour of Gitea in contrast is to always display the avatar and information related to a signature. This allows signatures to be decoupled from the committer. That being said, allowing arbitary users to present other peoples commits as theirs is not necessarily desired therefore we have a trust model whereby signatures from collaborators are marked trusted, signatures matching the commit line are marked untrusted and signatures that match a user in the db but not the committer line are marked unmatched. The problem with this model is that this conflicts with Github therefore we need to provide an option to allow users to choose the Github model should they wish to. Signed-off-by: Andrew Thornton <art27@cantab.net> * Adjust locale strings Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @6543 Co-authored-by: 6543 <6543@obermui.de> * Update models/gpg_key.go * Add migration for repository Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-19 12:44:55 -04:00
committer = signer
}
} else {
commitTreeOpts.NoGPGSign = true
}
Add configurable Trust Models (#11712) * Add configurable Trust Models Gitea's default signature verification model differs from GitHub. GitHub uses signatures to verify that the committer is who they say they are - meaning that when GitHub makes a signed commit it must be the committer. The GitHub model prevents re-publishing of commits after revocation of a key and prevents re-signing of other people's commits to create a completely trusted repository signed by one key or a set of trusted keys. The default behaviour of Gitea in contrast is to always display the avatar and information related to a signature. This allows signatures to be decoupled from the committer. That being said, allowing arbitary users to present other peoples commits as theirs is not necessarily desired therefore we have a trust model whereby signatures from collaborators are marked trusted, signatures matching the commit line are marked untrusted and signatures that match a user in the db but not the committer line are marked unmatched. The problem with this model is that this conflicts with Github therefore we need to provide an option to allow users to choose the Github model should they wish to. Signed-off-by: Andrew Thornton <art27@cantab.net> * Adjust locale strings Signed-off-by: Andrew Thornton <art27@cantab.net> * as per @6543 Co-authored-by: 6543 <6543@obermui.de> * Update models/gpg_key.go * Add migration for repository Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-19 12:44:55 -04:00
commitHash, err := gitRepo.CommitTree(doer.NewGitSig(), committer, tree, commitTreeOpts)
if err != nil {
return err
}
if err := git.Push(gitRepo.Ctx, basePath, git.PushOptions{
Remote: DefaultRemote,
[GITEA] Allow changing the repo Wiki branch to main Previously, the repo wiki was hardcoded to use `master` as its branch, this change makes it possible to use `main` (or something else, governed by `[repository].DEFAULT_BRANCH`, a setting that already exists and defaults to `main`). The way it is done is that a new column is added to the `repository` table: `wiki_branch`. The migration will make existing repositories default to `master`, for compatibility's sake, even if they don't have a Wiki (because it's easier to do that). Newly created repositories will default to `[repository].DEFAULT_BRANCH` instead. The Wiki service was updated to use the branch name stored in the database, and fall back to the default if it is empty. Old repositories with Wikis using the older `master` branch will have the option to do a one-time transition to `main`, available via the repository settings in the "Danger Zone". This option will only be available for repositories that have the internal wiki enabled, it is not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`. When migrating a repository with a Wiki, Forgejo will use the same branch name for the wiki as the source repository did. If that's not the same as the default, the option to normalize it will be available after the migration's done. Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will now include the wiki branch name in `GET` requests, and allow changing the wiki branch via `PATCH`. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu> (cherry picked from commit d87c526d2a313fa45093ab49b78bb30322b33298)
2024-01-30 06:18:53 -05:00
Branch: fmt.Sprintf("%s:%s%s", commitHash.String(), git.BranchPrefix, repo.GetWikiBranchName()),
Env: repo_module.FullPushingEnvironment(
doer,
doer,
repo,
repo.Name+".wiki",
0,
),
}); err != nil {
if git.IsErrPushOutOfDate(err) || git.IsErrPushRejected(err) {
return err
}
return fmt.Errorf("Push: %w", err)
}
return nil
}
// DeleteWiki removes the actual and local copy of repository wiki.
func DeleteWiki(ctx context.Context, repo *repo_model.Repository) error {
if err := repo_service.UpdateRepositoryUnits(ctx, repo, nil, []unit.Type{unit.TypeWiki}); err != nil {
return err
}
system_model.RemoveAllWithNotice(ctx, "Delete repository wiki", repo.WikiPath())
return nil
}
func SearchWikiContents(ctx context.Context, repo *repo_model.Repository, keyword string) ([]*git.GrepResult, error) {
gitRepo, err := git.OpenRepository(ctx, repo.WikiPath())
if err != nil {
return nil, err
}
defer gitRepo.Close()
return git.GrepSearch(ctx, gitRepo, keyword, git.GrepOptions{
ContextLineNumber: 0,
IsFuzzy: true,
RefName: repo.GetWikiBranchName(),
MaxResultLimit: 10,
MatchesPerFile: 3,
})
}