Repository navigation
Added BBS environment reset code for e2e tests - #733
Conversation
3449804 to
0a9d2de
Compare
Integration Test Results5 tests ±0 5 ✔️ ±0 16m 16s ⏱️ - 17m 54s Results for commit a575d50. ± Comparison against base commit 27a45d7. This pull request removes 1 and adds 1 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
synthead
left a comment
There was a problem hiding this comment.
LGTM! I added a couple comments for things we could improve on with over efforts of work 🙃
| [Fact] | ||
| public async Task Basic() | ||
| [Theory] | ||
| [InlineData("http://e2e-bbs-8-5-0-linux-2204.eastus.cloudapp.azure.com:7990")] |
There was a problem hiding this comment.
Can we add an issue to make the server use HTTPS? We should probably rotate the credentials as part of this effort, too 😉
| Repository.Init(repoPath); | ||
| using var repo = new Repository(repoPath); | ||
| File.WriteAllText(Path.Join(repo.Info.WorkingDirectory, "README.md"), "# Test Repo"); | ||
| repo.Index.Add("README.md"); | ||
| repo.Index.Write(); | ||
| var author = new Signature("Octoshift", "octoshift@github.com", DateTime.Now); | ||
| repo.Commit("Here's a commit i made!", author, author); |
There was a problem hiding this comment.
We spoke about how you're interested in also creating PRs and such with the BBS API sometime in the future. With this code, a unique commit ID will be created every time it is executed, which will also mean that we will need to use unique payloads to create the PRs.
We could use a Git fixture (that could even be stored as a repo in GitHub), but we could also go the full nine yards and use Atlassian's own migration tools to store test data 😄 This strategy would use the same archives that we're consuming in Octoshift, and we can use their first-party tools to do the work.
This has the potential to save us a lot of time in creating our test data. In addition, we wouldn't need to use Git libraries, and it would reduce network requests made to set up the data. We could also use our own fixtures as test data, too.
Here is Atlassian's doc for migrating from and to BBS servers with migration archives: https://confluence.atlassian.com/bitbucketserver/migrating-bitbucket-server-to-another-server-776640406.html
This is certainly up for conversation and should definitely not be addressed in this PR, but I think there would be value in creating an issue to track this possibility 👍
Added code to do a similar thing we do with our other e2e tests, where the test is responsible for resetting the test data that it expects in the test environment. This makes it easy to stand up new environments, and prevent accidentally breaking test environments by unintentional manual changes in the BBS server(s). It also makes it easy to add new data shapes to our test environments, as we just add them in one place (in the code) rather than having to manually touch each of our BBS test servers (and we will have several of them before we're done with the BBS work).
Right now these additions will check if the BBS project exists, and if so iterate and delete all repos in the project, then delete the project. Then create the project(s) and repo(s) from scratch.
It uses libgit2sharp to initialize the repos. This dependency only exists in our e2e test code, not in the CLI that we ship to customers. libgit2sharp comes with native binaries for various linux distro's, but only includes ubuntu 18.04 but our build servers use ubuntu 20.04 (or maybe 22.04). The workaround is to use the LD_LIBRARY_PATH env var when building our integration test project to force it to link to the ubuntu 18.04 binary (libgit2/libgit2sharp#1703 (comment))
This has pretty much everything we need to support testing against BBS 5.14 also (#570 ) except for some reason the initialize repo code fails consistently when run against BBS 5.14. Once somebody figures out why that fails, you just need to add an extra [InlineData] attribute to the test case and it will run for both.
Closes #573