Consider adding removing the class or move the printing methods to the GitCommitTracker.

I suggest removing the GitCommitTracker class + tests, as this was used to make sure the commits were ordered. Now we rely on the controller to do that for us.

Prerequitesites: #79 #52

Add a front-end web-application that you write with .Net Blazor (WebAssembly) to your already existing applications. That front-end application interacts with your GitInsight back-end application via the REST API that you implemented last week.

The front-end application should be able to receive the identifier of a GitHub repository (<github_user>/<repository_name> or <github_organization>/<repository_name> as described for last week, see above) via a suitable input field.

The data will be visualized in another issue.

Additionally, in your GitInsight back-end applications implement a new analysis. It should be able to list all forks of a repository on GitHub. To do so, it should call the GitHub REST API and collect a list of all forks from a given repository. That is, when your GitInsight REST API receives a GET request with a GitHub repository identifier of the form <github_user>/<repository_name> or <github_organization>/<repository_name>, then besides the two already existing analyses of cloned Git repositories your application contacts the GitHub REST API to collect the number of forks of that repository.

To connect to the GitHub REST API, you need an Access Token. Read this documentation on how to receive an Access Token for the GitHub REST API. Remember and double check on how Rasmus demonstrated to handle secrets like access tokens in .Net projects. That is, do not store the access token directly in your source code. It should never end up in your source code repository that is publicly shared with the world.

Your presentations should include the following:

How do you make sure that you implemented the right application?
That is, provide a mapping from functional and non-functional requirements in text form to respective test cases.
Show what kind of tests are contained in your test suites and demonstrate what they are testing.
Did you apply any design patterns in your application?
If yes, describe where you applied which design pattern and what problem it solves, i.e., the reason for its application.
You choose if you present design patterns in code over via diagrams that illustrate them.
Did you apply any architectural patterns in your application?
If yes, describe where you applied which architectural pattern and describe the reason for its application.
Likely, architectural patterns in your application are best illustrated using suitable diagrams.
Did you follow any design principles?
If yes, show case some instances of
Present UML diagrams for aspects of your applications that you want to highlight during your presentation, e.g., the structure of your applications, important interactions of certain classes, component, or sub-systems, etc.

We cannot call the Github API through Github actions, without using an access token in the Github actions workflow like we setup on our local machines. I see three solutions:

1. It might be possible to create a Github token for this and use dependency injection during tests. Probably the best but hardest solution as we then also test the Github API and not just our own controller.
2. Moq the Github API and just test our controller
3. Test these things locally but skip them on Github Actions workflow. Requires a lot of work whenever we change things in the Github API controller, as we need to remove the Skip attribute, test it locally, put the add in the skip attribute again and push to a Github pull request. This is the easiest but requires the most work solution.

If anyone is up for seeing if the first is possible, that'd be really awesome. But I am unsure from the documentation how to receive the token in the code and use it in the constructor of the test class. Otherwise, 2 is also a valid solution that allows us not to worry about the tests when testing locally nor when testing on Github Actions.

Now that your application changed, update the documentation of your GitInsight applications to reflect the current state of the application. For sure, update the architecture illustration from last week. Likely it is a good idea to illustrate how the front-end and the back-end interact when a new analysis is triggered via a sequence diagram. In this case the it will be a sub-system sequence diagram where the blocks on top of swim lanes represent the front-end, back-end, and other systems as sub-systems instead of objects as shown multiple times in lectures, see for example here.

#93 shows that changing test structure breaks a lot of tests relating to unzipping files, and some of the stacktraces seems to mention that files are missing / not located where they were expected.
These tests pass locally on both Windows & MacOS, so we need to figure out how to refactor them to pass on Github Actions and then remove the Skip attribute on [Theory]s and [Fact]s.

Includes moving libgit2sharp to PersistantStorage and remove from GitInsight program

Only "ReadAllCommits" should be public method.

Use nuget package

So far, your GitInsight applications can be assessed by anybody with access to the application's URL via a browser. Also, the REST API of the back-end's can be accessed by anybody that knows the corresponding URL. This week you extend you GitInsight applications with a feature that restricts access only to authorized users. That is, based on the contents of Rasmus' lecture on security you modify your applications so that users have to authenticate themselves before they are able to analyze a GitHub repository. This authentication should hold for the front-end web-application as well as for the back-and REST API.

Additionally, make sure that all communication between your front-end application communicates and your back-end application (see last week's project description) is encrypted.

Dependency injection of IPersistantStorage with MSSQL database from Program.cs to GitCommitTracker

Refactor GitCommitTracker to receive IEnumerable

Either change to zip file or make a moq

Prerequisite: #79 is merged into main

Implement visualizations to your .Net Blazor front-ends that look similar to those in the illustrations on top of this page. These visualizations should present the results of the two analyses that you already implemented in your GitInsight applications, i.e., the commit frequencies over time and the and the commit frequencies over time per author. You might want to use bar charts or another suitable chart type to present the analyses results.

The data will come from #80 but can be developed via dummy data for now.

• Create a restful web API using ASP.NET Minimal APIs

Prerequisite: #79 #82

Implement a visualization of the forks of a GitHub repository as a third visualization. It might just be a list view similar as illustrated on top. In case you find a more suitable visualization, you are free to choose that instead.

Use dummy data until #82 is completed.

• Update the functional and non-functional requirement

Make a structural diagram

Implement an analysis and visualization of your choice in your GitInsight applications. For example, you might want to identify and present those files that change most often/least often, those files that change most often together (i.e., they appear in commits together, which is called logical coupling), identify groups of authors that work often on the same files, etc.

Make sure that the new features and analyses are covered by appropriate tests in your test suites.

NOTE
Can be separated into frontend + backend when a decision of what visualization and which data structures are necessary has been made.

Stacktrace when trying to analyze an invalid github repository is bad. It should be cleaner than the below:

LibGit2Sharp.LibGit2SharpException: remote authentication required but no callback set
   at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
   at LibGit2Sharp.Core.Ensure.ZeroResult(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 172
   at LibGit2Sharp.Core.Proxy.git_clone(String url, String workdir, GitCloneOptions& opts) in /_/LibGit2Sharp/Core/Proxy.cs:line 278
   at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, CloneOptions options) in /_/LibGit2Sharp/Repository.cs:line 793
   at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath) in /_/LibGit2Sharp/Repository.cs:line 727
   at GitInsight.PersistentStorageController.FindAllGithubCommits(String organizationName, String repositoryName)
   at GitInsight.RestAPI.Program.<>c__DisplayClass1_0.<<-ctor>b__0>d.MoveNext() in /Users/Guldborg/Projects/ITU/BDSA/GitInsight/GitInsight.RestAPI/Program.cs:line 43
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Http.RequestDelegateFactory.<ExecuteTask>g__ExecuteAwaited|58_0[T](Task`1 task, HttpContext httpContext)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

HEADERS
=======
Accept: application/json
Connection: keep-alive
Host: localhost:7283
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,pt;q=0.7
Cookie: Idea-fdf72ce5=f486b569-27d0-44c7-8547-176b31fd3991; Idea-b72b7fc0=bfae7e87-53f0-4930-bcb6-479283be8002
Referer: https://localhost:7283/swagger/index.html
sec-ch-ua: ".Not/A)Brand";v="99", "Google Chrome";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty

Implement TaskedResult so we can handle further response codes, not just:
200 OK
500 Internal server error

This includes validating responses (Can we remove the validRepository endpoint, call it each time in backend and return an appropriate response code if invalid?)