improve integration test to resue models/fixtures and store git repos with tests

[lunny]

Since there are two fixtures, I will remove the fixtures in the integration.tar.gz and only keep git repos in the .tar.gz. Also I keep the .tar.gz with the tests and not download from network so that we can keep the meta data with the tests synchronism.

[andreynering]

Trusted LGTM

I agree that tests should not require internet connection.

Different fixture folders are not necessarally bad if you have different data there. Are fixtures of integration tests different from models @ethantkoenig ?

[andreynering]

Also, maybe get rid of the .tar.gz file, and just store it as is like https://github.com/ethantkoenig/gitea-integration ?

Could be in another PR to not block this one.

[sapk]

Following @andreynering proposition of storing file and not .tar.gz we could vendor it to "easely" follow modification to data set. And like you propose doing it in an other PR is good also.

[sapk]

I haven't check content of gitea-integration.tar.gz but I can trust LGTM.

[lunny]

I think store as .tar.gz is better since there .git folders in the repos.

[appleboy]

LGTM

[andreynering]

I think store as .tar.gz is better since there .git folders in the repos.

@lunny I they were called .git, Git would reconize them as Git repos. But they're actually called {{repoName}}.git, so no problem.

[ethantkoenig]

This won't work, since the fixtures in models/fixtures don't match the repos in gitea-integration.tar.gz

If we want to reuse fixtures between unit tests and integration tests, we will need to update gitea-integration.tar.gz accordingly.

[lunny]

@ethantkoenig yes, you are right. I have updated the file integration.tar.gz on this PR.

[lunny]

@andreynering sure, you are right. There is no .git folder only xxxx.git folder. So seems it's no need to store as .tar.gz file.

[ethantkoenig]

@lunny We're still missing repositories for every repo other than user2/repo1

Is there a reason we need to use the same fixtures for unit tests and integration tests?

[lunny]

@ethantkoenig use the same fixtures will let us test the data entirely. Two fixtures are always confusing me which one I'm testing. The missing repository could be added in other future PRs. Currently It's enough.

[strk]

Could those git repositories be created at runtime rather than being included in the source ?
Just a setup phase issuing git commands...

[lunny]

@strk, I store it in a .tag.gz before and unzip it when test is running. Just changed to this form.

[sapk]

It would be better to have fixture data in a other repo maybe but this good enough to start using integration test.

[ethantkoenig]

@sapk That was the solution I had in mind with https://github.com/ethantkoenig/gitea-integration. I had hoped/planned to eventually transfer ownership of that repo to @go-gitea

[ethantkoenig]

Not a huge fan of having inconsistencies between fixtures and repositories, but I'll approve to help move things along.

[bkcsoft]

I'd really prefer if we generated repositories based on the repos. But that might not be doable?

[lunny]

@ethantkoenig I would like keep the testdata here for version control. Put it a seperate repo seems not necessary. I will merge this at first. Please feel free to discuss here.

[lunny]

@bkcsoft Do you mean generate repository according the fixtures records?

[bkcsoft]

@lunny yes. Basically read the fixtures into arrays and create repos out of that

[lunny]

I'm thinking generate the visit URL according fixtures repos so that we can test all the routes.

[ethantkoenig]

I'm not sure how generating repositories from fixtures would work. It seems that there is a lot of state stored in repositories (mostly commit history) that can't be inferred from fixtures.

For example, for each merged entry in the pull_request table, we would need to somehow generate a commit whose SHA-1 hash matches the corresponding merged_commit_id.