* Make test work with different default branch config
On a system configured with a different default branch name, doGitInitTestRepository
will create a repository with a branch named differently, and so further tests
would break:
--- FAIL: TestGit/HTTP/PushCreate/SuccessfullyPushAndCreateTestRepository (0.02s)
git_helper_for_declarative_test.go:167:
Error Trace: git_helper_for_declarative_test.go:167
Error: Received unexpected error:
exit status 1 - error: src refspec master does not match any
error: failed to push some refs to 'http://127.0.0.1:3003/user2/repo-tmp-push-create-http.git'
Test: TestGit/HTTP/PushCreate/SuccessfullyPushAndCreateTestRepository
git_test.go:587:
Error Trace: git_test.go:587
Error: Received unexpected error:
repository does not exist [id: 0, uid: 0, owner_name: user2, name: repo-tmp-push-create-http]
Test: TestGit/HTTP/PushCreate
* Update integrations/git_helper_for_declarative_test.go
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Benchmark Integration TESTS
* CI: add benching-arm64 pipeline
* BenchmarkRepo: name test case tests
* Fix BenchmarkRepoBranchCommit beside Create new Branch
* CI: benching use amd64
* rm total broken "BenchmarkRepo"
* dont run benchmark in CI
* remove github.com/unknwon/com from models
* dont use "com.ToStr()"
* replace "com.ToStr" with "fmt.Sprint" where its easy to do
* more refactor
* fix test
* just "proxy" Copy func for now
* as per @lunny
Replace all calls to os.Remove/os.RemoveAll by retrying util.Remove/util.RemoveAll and remove circular dependencies from util.
Fix #12339
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: silverwind <me@silverwind.io>
Reduce the code duplication in the PushCreate test and switch
to a declarative format.
* Instead of explicitly creating the repository re-use functions from the other declarative tests and add comments
* Ensure that the test repository is deleted at the end of test
* Slightly reorder the sub-tests
Also reduce the code duplication in MergeFork and add some comments there too and make doGitCloneFail be self-contained.
Signed-off-by: Andrew Thornton art27@cantab.net
* Fix the intermittent TestGPGGit failures
Reattempt to open the listener if the port is busy with a delay up to a second
Switch from generating a private key each time, just use a known good key
* Yet another attempt to fix the race in gpg_git_test
* add some fail nows
* Need to set preparetestenv
* Ensure that http messages go to the correct server
* Change tests to make it possible to run TestGit with 1.7.2
* Make merge run on 1.7.2
* Fix tracking and staging branch name problem
* Ensure that git 1.7.2 works on tests
* ensure that there is no chance for conflicts
* Fix-up missing merge issues
* Final rm
* Ensure LFS filters run on the tests
* Do not sign commits from temp repo
* Restore tracking fetch change
* Apply suggestions from code review
* Update modules/repofiles/temp_repo.go
* Rename BaseLogger to WriterLogger to help the creation of other providers
* Don't export ColorBytes and ResetBytes from ColoredValues
* Make integration tests only print logs if they fail
* check can color before coloring
* I always forget about MSSQL
* Oh and use LEVEL in sqlite.ini
* Make the test logger log at info - as it means you see the router
* Remove empty expected changes
* Make the migrations quieter too
* Don't display SQL on error - it can be looked at in the file logs if necessary
* Fix skip when using onGiteaRun
* use native golang SSH library but ssh-keygen when enable built-in SSH server to remove dependent on that command lines
* fix tests and add comment head
1. A key can either be an ssh user key or a deploy key. It cannot be both.
2. If a key is a user key - it can only be associated with one user.
3. If a key is a deploy key - it can be used in multiple repositories and the permissions it has on those repositories can be different.
4. If a repository is deleted, its deploy keys must be deleted too.
We currently don't enforce any of this and multiple repositories access with different permissions doesn't work at all. This PR enforces the following constraints:
- [x] You should not be able to add the same user key as another user
- [x] You should not be able to add a ssh user key which is being used as a deploy key
- [x] You should not be able to add a ssh deploy key which is being used as a user key
- [x] If you add an ssh deploy key to another repository you should be able to use it in different modes without losing the ability to use it in the other mode.
- [x] If you delete a repository you must delete all its deploy keys.
Fix #1357
