summaryrefslogtreecommitdiffstats
path: root/services/repository/fork.go
Commit message (Collapse)AuthorAgeFilesLines
* Use context parameter in services/repository (#23186)Jason Song2023-02-281-2/+2
| | | | | | | | Use context parameter in `services/repository`. And use `cache.WithCacheContext(ctx)` to generate push action history feeds. Fix #23160
* Repositories: by default disable all units except code and pulls on forks ↵techknowlogick2023-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | (#22541) Most of the time forks are used for contributing code only, so not having issues, projects, release and packages is a better default for such cases. They can still be enabled in the settings. A new option `DEFAULT_FORK_REPO_UNITS` is added to configure the default units on forks. Also add missing `repo.packages` unit to documentation. code by: @brechtvl ## :warning: BREAKING :warning: When forking a repository, the fork will now have issues, projects, releases, packages and wiki disabled. These can be enabled in the repository settings afterwards. To change back to the previous default behavior, configure `DEFAULT_FORK_REPO_UNITS` to be the same value as `DEFAULT_REPO_UNITS`. Co-authored-by: Brecht Van Lommel <brecht@blender.org>
* Add option to prohibit fork if user reached maximum limit of repositories ↵Xinyu Zhou2022-12-271-0/+7
| | | | | | | | | | | | | | | | | | (#21848) If user has reached the maximum limit of repositories: - Before - disallow create - allow fork without limit - This patch: - disallow create - disallow fork - Add option `ALLOW_FORK_WITHOUT_MAXIMUM_LIMIT` (Default **true**) : enable this allow user fork repositories without maximum number limit fixed https://github.com/go-gitea/gitea/issues/21847 Signed-off-by: Xinyu Zhou <i@sourcehut.net>
* refactor some functions to support ctx as first parameter (#21878)Lunny Xiao2022-12-031-1/+1
| | | | Co-authored-by: KN4CK3R <admin@oldschoolhack.me> Co-authored-by: Lauris BH <lauris@nix.lv>
* Implement FSFE REUSE for golang files (#21840)flynnnnnnnnnn2022-11-271-2/+1
| | | | | | | | | Change all license headers to comply with REUSE specification. Fix #16132 Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github> Co-authored-by: John Olheiser <john.olheiser@gmail.com>
* Add `context.Context` to more methods (#21546)KN4CK3R2022-11-191-1/+1
| | | | | | | This PR adds a context parameter to a bunch of methods. Some helper `xxxCtx()` methods got replaced with the normal name now. Co-authored-by: delvh <dev.lh@web.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Allow detect whether it's in a database transaction for a context.Context ↵Lunny Xiao2022-11-121-2/+2
| | | | | | | | | | | | | | | | (#21756) Fix #19513 This PR introduce a new db method `InTransaction(context.Context)`, and also builtin check on `db.TxContext` and `db.WithTx`. There is also a new method `db.AutoTx` has been introduced but could be used by other PRs. `WithTx` will always open a new transaction, if a transaction exist in context, return an error. `AutoTx` will try to open a new transaction if no transaction exist in context. That means it will always enter a transaction if there is no error. Co-authored-by: delvh <dev.lh@web.de> Co-authored-by: 6543 <6543@obermui.de>
* Replace all instances of fmt.Errorf(%v) with fmt.Errorf(%w) (#21551)delvh2022-10-241-4/+4
| | | | | | | | | Found using `find . -type f -name '*.go' -print -exec vim {} -c ':%s/fmt\.Errorf(\(.*\)%v\(.*\)err/fmt.Errorf(\1%w\2err/g' -c ':wq' \;` Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Andrew Thornton <art27@cantab.net> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Refactor git command arguments and make all arguments to be safe to be used ↵wxiaoguang2022-10-231-1/+1
| | | | | | | (#21535) Follow #21464 Make all git command arguments strictly safe. Most changes are one-to-one replacing, keep all existing logic.
* Make every not exist error unwrappable to a fs.ErrNotExist (#20891)zeripath2022-10-181-0/+4
| | | | | | | | | | | | | | | | | | | | A lot of our code is repeatedly testing if individual errors are specific types of Not Exist errors. This is repetitative and unnecesary. `Unwrap() error` provides a common way of labelling an error as a NotExist error and we can/should use this. This PR has chosen to use the common `io/fs` errors e.g. `fs.ErrNotExist` for our errors. This is in some ways not completely correct as these are not filesystem errors but it seems like a reasonable thing to do and would allow us to simplify a lot of our code to `errors.Is(err, fs.ErrNotExist)` instead of `package.IsErr...NotExist(err)` I am open to suggestions to use a different base error - perhaps `models/db.ErrNotExist` if that would be felt to be better. Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: delvh <dev.lh@web.de>
* Move some files into models' sub packages (#20262)Lunny Xiao2022-08-251-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | * Move some files into models' sub packages * Move functions * merge main branch * Fix check * fix check * Fix some tests * Fix lint * Fix lint * Revert lint changes * Fix error comments * Fix lint Co-authored-by: 6543 <6543@obermui.de>
* Move some code into models/git (#19879)Lunny Xiao2022-06-121-1/+2
| | | | | | | | | | | | | | | | | | | * Move access and repo permission to models/perm/access * fix test * Move some git related files into sub package models/git * Fix build * fix git test * move lfs to sub package * move more git related functions to models/git * Move functions sequence * Some improvements per @KN4CK3R and @delvh
* Move some repository related code into sub package (#19711)Lunny Xiao2022-06-061-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Move some repository related code into sub package * Move more repository functions out of models * Fix lint * Some performance optimization for webhooks and others * some refactors * Fix lint * Fix * Update modules/repository/delete.go Co-authored-by: delvh <dev.lh@web.de> * Fix test * Merge * Fix test * Fix test * Fix test * Fix test Co-authored-by: delvh <dev.lh@web.de>
* Remove `git.Command.Run` and `git.Command.RunInDir*` (#19280)wxiaoguang2022-04-011-3/+3
| | | | | | Follows #19266, #8553, Close #18553, now there are only three `Run..(&RunOpts{})` functions. * before: `stdout, err := RunInDir(path)` * now: `stdout, _, err := RunStdString(&git.RunOpts{Dir:path})`
* Refactor `git.Command.Run*`, introduce `RunWithContextString` and ↵wxiaoguang2022-03-311-2/+2
| | | | | | | | | | | | | | | | | | `RunWithContextBytes` (#19266) This follows * https://github.com/go-gitea/gitea/issues/18553 Introduce `RunWithContextString` and `RunWithContextBytes` to help the refactoring. Add related unit tests. They keep the same behavior to save stderr into err.Error() as `RunInXxx` before. Remove `RunInDirTimeoutPipeline` `RunInDirTimeoutFullPipeline` `RunInDirTimeout` `RunInDirTimeoutEnv` `RunInDirPipeline` `RunInDirFullPipeline` `RunTimeout`, `RunInDirTimeoutEnvPipeline`, `RunInDirTimeoutEnvFullPipeline`, `RunInDirTimeoutEnvFullPipelineFunc`. Then remaining `RunInDir` `RunInDirBytes` `RunInDirWithEnv` can be easily refactored in next PR with a simple search & replace: * before: `stdout, err := RunInDir(path)` * next: `stdout, _, err := RunWithContextString(&git.RunContext{Dir:path})` Other changes: 1. When `timeout <= 0`, use default. Because `timeout==0` is meaningless and could cause bugs. And now many functions becomes more simple, eg: `GitGcRepos` 9 lines to 1 line. `Fsck` 6 lines to 1 line. 2. Only set defaultCommandExecutionTimeout when the option `setting.Git.Timeout.Default > 0`
* Make git.OpenRepository accept Context (#19260)65432022-03-301-11/+11
| | | | | * OpenRepositoryCtx -> OpenRepository * OpenRepository -> openRepositoryWithDefaultContext, only for internal usage
* Fix forked repositories missed tags (#18719)Lunny Xiao2022-02-121-1/+11
| | | | | | | | | * Fix forked repositories missed tags * Add missed close * Use ctx Co-authored-by: 6543 <6543@obermui.de>
* Delete old git.NewCommand() and use it as git.NewCommandContext() (#18552)65432022-02-061-2/+2
|
* Some repository refactors (#17950)Lunny Xiao2021-12-121-2/+9
| | | | | | | | | * some repository refactors * remove unnecessary code * Fix test * Remove unnecessary banner
* Move repository model into models/repo (#17933)Lunny Xiao2021-12-101-11/+11
| | | | | | | | | | | | | | | * Some refactors related repository model * Move more methods out of repository * Move repository into models/repo * Fix test * Fix test * some improvements * Remove unnecessary function
* Move user related model into models/user (#17781)Lunny Xiao2021-11-241-1/+2
| | | | | | | | | | | | | * Move user related model into models/user * Fix lint for windows * Fix windows lint * Fix windows lint * Move some tests in models * Merge
* Move some functions into services/repository (#17660)Lunny Xiao2021-11-161-0/+175
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-05 02:38:43 +0000
he rest of the application to the application server. The mode is set with a `vaadin.widgetset.mode` property in the [elementname]#properties# section at the beginning of the project POM. [[addons.maven.modes.local]] === Local Widget Set Compilation If add-ons are detected, an [filename]#AppWidgetset.gwt.xml# descriptor file is generated into the [filename]#generated-resources# folder, and later updated automatically. The compiler uses the descriptor to compile the widget set, which is included in the web application archive. .Local widget set compilation image::img/widgetset-mode-local.png[width=80%, scaledwidth=60%] Local compilation is needed in projects that have custom widgets or widget sets that are not available from the Maven central repository or from the Vaadin add-ons or pre-releases repositories. Local compilation is necessary for completely offline work. Local compilation is currently the default mode. It is therefore not necessary to set it explicitly, unless you have made global Maven settings and want to override them in a particular project. You can set the `local` parameter in the [elementname]#properties# section of your [filename]#pom.xml#: [source, xml] ---- <properties> ... <vaadin.widgetset.mode>local</vaadin.widgetset.mode> </properties> ... ---- [[addons.maven.modes.cdn]] === Online Widget Set Compilation and CDN The online compilation service makes it easier to use add-on components in Vaadin applications, by avoiding compilation of widget sets locally. It caches the widget sets, so often one is available immediately. A widget set can combine widgets from multiple add-ons and if a particular combination does not already exist, the service automatically compiles it. .Online widget set compilation and CDN image::img/widgetset-mode-cdn.png[width=80%, scaledwidth=100%] The CDN (Content Delivery Network) is a global network of web servers that serve the cached widget sets directly when you load your application in your browser. Avoiding local compilation can speed up development significantly. In development teams, all can use the shared widget sets immediately. [TIP] ==== While this gives benefits, the application will not work without online connnectivity. When you need to avoid the demo effect, either use the `local` or `fetch` mode. ==== The cloud service compiles a widget set with a given Vaadin version and a list of add-ons installed in your project. The Maven plug-in receives a public URL where the widget set is available and generates an [filename]#AppWidgetset.java# file that configures your application to use the online version. The file is generated to the default Java package. [NOTE] ==== Online compilation and CDN can only be used with publicly available add-ons. This means that the add-on dependencies must be available in the Maven central repository or in the Vaadin add-ons or pre-releases repositories. If you have custom widget implementations or non-public add-ons in your sources, you cannot use the online compilation and CDN service. ==== ==== Enabling Compilation To enable online compilation and delivery from the CDN, set the widget set mode to `cdn` in the [elementname]#properties# section of your [filename]#pom.xml#: [source, xml] ---- <properties> ... <vaadin.widgetset.mode>cdn</vaadin.widgetset.mode> </properties> ... ---- When using the online compilation service, a [interfacename]#WidgetsetInfo# implementation is generated for your project; this makes it possible for your application to find the widget set from the correct location. [NOTE] ==== *The CDN is not meant to be used in production.* It is are meant for speeding up development for yourself and your team. It is also useful if you maintain your source code in GitHub or a similar service, so that your globally working development team can immediately use the widget sets without need to compile them. For production, especially in intranet applications, you should normally use the `local` or `fetch` modes. This ensures that separating the availability of the Vaadin CDN service from availability of the application server does not add an extra point of failure. _They can be used for production_ if your application is intended as globally available, you want to gain the global delivery benefit of the Vaadin CDN, and the availability tradeoff is not significant. ==== === Serving Remotely Compiled Widget Set Locally If you want to use online compilation, but still serve the files as part of your application, you can use the `fetch` mode. .Fetching online widget set compilation image::img/widgetset-mode-fetch.png[width=80%, scaledwidth=100%] The Maven plugin downloads the compiled widget set into the project as it was compiled locally. It generates an [classname]#AppWidgetset# class and used to provide a correct URL to the locally stored widget set. To enable the fetch mode, in the [elementname]#properties# section of your [filename]#pom.xml#: [source, xml] ---- <properties> ... <vaadin.widgetset.mode>fetch</vaadin.widgetset.mode> </properties> ... ---- // TODO This is recommended during development, as it avoids slow local compilation and typically. (((range="endofrange", startref="term.addons.maven")))
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-05 02:38:42 +0000