JUnit tests fail due to missing hello-world.git on GitHub

[dbywalec]

I have recently discovered that repository "https://github.com/git/hello-world.git" referenced in JUnit tests had disappeared from GitHub and does not exist anymore.

For this reason a number of JUnit tests fail.

	public static void setUp() throws Exception {
		startGitblit();

		if (REPOSITORIES.exists() || REPOSITORIES.mkdirs()) {
			cloneOrFetch("helloworld.git", "https://github.com/git/hello-world.git");
			cloneOrFetch("ticgit.git", "https://github.com/schacon/ticgit.git");
			cloneOrFetch("test/jgit.git", "https://github.com/eclipse/jgit.git");
			cloneOrFetch("test/helloworld.git", "https://github.com/git/hello-world.git");
			cloneOrFetch("test/ambition.git", "https://github.com/defunkt/ambition.git");
			cloneOrFetch("test/gitective.git", "https://github.com/kevinsawicki/gitective.git");

			showRemoteBranches("ticgit.git");
			automaticallyTagBranchTips("ticgit.git");
			showRemoteBranches("test/jgit.git");
			automaticallyTagBranchTips("test/jgit.git");
		}
	}

Could not all repositories used in tests be forked into "gitblit" account on GutHub in order to make them independent?
This is probably a big simile towards James, the author and owner. 😄

[flaix]

Either that, or have test repositories zipped and checked in to the project as a test resource. I would actually see benefit in the latter as it allows for running tests in an environment where you don't have access to GitHub repos, and you also always have a well defined state of the repository used for tests, which also enabled running tests writing to the repository.

[rnveach]

This is similar to #1126 .

I recommend creating repositories at runtime.
Example: rnveach@d4b7fec#diff-40dc38b8e1cc8224c3b9602657444c93R82

Having a fixed or read-only repositories confines you to having that specific repository in that specific state. Any modifications done to the repository during a test, like deleting a branch, has to be undone for the next test otherwise they will fail. As tests need to expand to cover more areas, it will cause the read-only repository to become huge and bloated as more and more has to be added to it.
I believe this is how jgit does it's testing too.

[wbrawner]

I'm not sure how the leadership hierarchy works for the project, or how decisions are usually made. Which method should I go for? Or do I just choose the one that makes the most sense to me? Personally I think zipping up the data and keeping it in the test sources makes the most sense, but I'd still like to contribute according to your guidelines

[rnveach]

@wbrawner I'm not sure there is any leadership right now. See #1265 .
I was only giving my opinion.

[flaix]

Creating a repo on-the-fly for each test has the benefit that it is more easily adjustable and extendible. It has the drawback that with a lot of tests it can explode into a lot of code for creating repos and an increased runtime for tests.
Having a static, pre-filled repo that is only unzipped for each test has the benefit that it can be reused for many tests and simply unzipping it is probably faster than creating a repo from scratch for more complicated test cases. It has the drawback that extending it for one test can influence other tests and that it is a binary checked in.

Go with your gut feeling and choose what makes most sense to you. That way you will be most comfortable with implementing it. The task of creating repositories to get tests working alone is a big task, be they dynmically or statically created, so keep the barrier for yourself low. Both way will help immensly and can be used not only for read-only tests but also for read-write tests.

I guess that in the future we will end up with a mix of both. But as rnveach has mentioned, having read-only repositories for tests is limiting. There is also merit in read-only, remote repositories, for example for testing the mirror functionality. But the quickest win right now will be in something that makes existing tests work again, and that can help with existing bug reports that require repo interaction to get tested.

[wbrawner]

@rnveach gotcha, thanks! I think I'll start with the quick fix of just zipping up the repos for now, and perhaps later investigate the repo creation on the fly.

@fzs Understood, thanks!