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
zeripath
Lunny Xiao
Tamal Saha
guillep2k