When providing an invalid repository on the one-time validation page, the resulting 404 page is misaligned and unpleasing to look at.

Refactor the resulting 404 page and provide a link back to the one-time validation page.

When validating a repository that contains files with missing annex content, the validation stops with an error message.

Ideally the validation should not be stopped, but should continue and each file with missing content should be reported as an individual error for each file.

The function TestValidateTMPFail tests that the validation fails, but because the problem is correctly delivered to the user, the result code of the request is 200 OK. The same applies to the test function TestValidateBadgeFail.

When running a public one-time validation, the text should give a hint to leave the page open and refresh to see the validation results.

On login the user should be redirected to a repository listing. For each repository, there should be a count showing the number of enabled hooks. On clicking the link of a repository, there should be a page that allows the user to enable or disable hooks for specific validators for the repository.

The results rendering functions (renderBidsResults() and renderNIXResults()) still duplicate a lot of code that could be moved to the Results() function. We could shrink these two functions so that :

• Make the main Results() function parse the layout template.
• The Results() function could also parse the template for each validator and then we can make the renderBidsResults() and renderNIXResults() functions simply return an interface{} which contains the data required to execute the template.

We could go one step further and have a single template for all validation results. Each function would then have to return a byte slice of their results as text instead of having them structured. The template would then simply add the text to the body of the common template.

If we format the output of the odML validation script, gin-valid can read it and format it accordingly into a nice template like we do for BIDS.

The web package currently features a couple of package wide constants and variables that are used in various files of the package. As a proposal:

Constants that are used in multiple files could be moved to its own settings.go or config.go file within the package and imported from there so we don't have to look for the file in which they are defined, e.g.

• cookie name "gin-valid-session"
• sessions
• usersession
• hookregs

Constants that we might not want to have in the code or would make sense to define on server level could also be handled in the settings and imported via the server config e.g.

• serveralias
• hooksecret
• clientID "gin-valid"

When running a validation on a non-BIDS repository, the "Results" page should not be a blank 500 page, but a full gin-valid page with an appropriate issue description and an option to return to the "one-time validation" or validator listing page.

Access control is very basic currently. Hooks can only be enabled by authorised users that have write access to a repository. Beyond that, it's all pretty open. Results are publicly visible and can easily be guessed since the URL is simply constructed from the repository path and the name of the validator.

• Limit access to results pages based on user access through GIN. We should probably use the token we store for the user to check for read access.
• Generate unique random identifiers for pub-validate results that are only available to the user that started the validation procedure.

To avoid any issues, the ServiceWaiter should always remain logged in, every user specific session should create and on finish delete its own session key.

We should probably support .yaml and .json odML files as well in the long run.

Originally posted by @mpsonntag in #37

Display user information in the page header if a user has logged into the gin-valid service.

Currently after a user has logged into the gin-valid service, the "Login" option is still displayed and active.

After a user has logged into the gin-valid service, the "Login" option should be replaced by a functioning "Logout" option.

If (annexed) content is not available yet, wait and retry. We would have to set a max timeout for this. The issue is that when a user does a 'gin upload' a push happens immediately and the hook is triggered, but annexed content is only transferred after the push and could take a while (hours?). The validation service should try to download content after the transfer is complete, or should keep retrying until it's available, with a timeout. We could also make it more efficient by only downloading the content in the directories which are specified in the validator config (if it exists).

If validation is requested for a certain validator+repository combination that is already running, don't trigger another run or kill the existing one if it's an older commit.

When choosing a one-time-validation and not selecting any validator, the server panics and the user is confronted with a "Secure connection failed" page.

Write a NIX validation script, like the odML script, that uses NIXPy (the nixpy validator could use some fixing up first), formats the output into JSON and prints it. Gin-valid can then read it and format it accordingly into a nice template like we do for BIDS.

Refactor the page displayed via the web/user.go:Login function when a login fails. Display additional information and a link back to the login page for now.

Some tests create output files in the working directory. Use ioutil.TempDir for all created test directories and files to keep the working directory clean.

On the repository listing page (/repos/user), separate active from inactive repositories. List repositories with active validator hooks first and then all the rest.

The previously used nixio-validate executable is no longer installed, the functionality has been integrated into the nixio executable. Usage has been changed from nixio-validate [nixfile(s)] to nixio validate [nixfile(s)].

Change the nixio validate usage accordingly in config.go and validate.go.

Currently requests get run immediately as they come in. We should implement a worker queue for managing concurrent jobs up to a configurable maximum.

When a request comes in, it should write the "In Progress" badge immediately and then queue up to run the validation.

A guide already exists that describes all the locations and functions that should be written to add a validator. We should include a concrete guide for how to add an example validator (that does nothing) that people can use as a template.

Currently when a logged in user views the validator listing page for a specific repository and there are no results for a specific validator yet, the "Results" link for this validator will lead to a blank page with only the text "404 Nothing to see here ...".

Provide a full page including header and footer, an appropriate information text and a link back to the results overview page of the repository.

If we want to reuse parts of the server for similar micro service servers, it might be useful to remove the gin-valid server config dependency from the logger.

When a user has a lot of repositories it can take very long for the service to get the full list in order to show it on the repo list page. The service should use paging or progressive loading to avoid having the page hang while waiting for a response.

For each validator the service knows to be enabled, verify with the server that the hook does in fact exist and is active. If a hook has been deleted from the GIN server, either remove it from the local store or warn the user that it's missing.

As a side-feature, avoid enabling duplicate hooks.

Use multiple versions of odML to validate old (v1) formatted files as well as the current version.

Don't block when running pubvalidate. Show a "running" page and redirect to the results once it's done.

Currently the (c) G-Node date in the footer line of each page is static. Replace the static end date with a dynamic one of to the current year.

We could have multiple nix-tool versions so that old files and newer ones can be validated accordingly.

When a repository is validated using ServiceWaiter via web/validate.go:PubValidate, only public repositories should be validated.

If we ever encounter a private repository in this route, fail with http.StatusUnauthorized and log all details.

The web packages makes use of a local fail function in case of internal server errors in multiple places. Make the function global and reuse it.

When a user lands on the root page (or even the login page), redirect them to their repo listing.

This will make it impossible for a logged in user to reach the manual validation form, so we should either add that to the repo listing or have it as a separate page.

Currently error pages (not found, unauthorised, etc) are just plain text.

We should probably restructure the validation process

• Once a validation has started, the service should create a processing badge for the commit and return, so the user does not have to wait until cloning and validation is done (which might take some time).
• Currently a validation process never returns an error. If something goes wrong during the validation an error should be returned here; if an error is present, the service should then replace the processing badge with an appropriate error badge. If no error is present it is assumed that the build went through and an appropriate badge has been created by the validation process.

Originally posted by @mpsonntag in #33

Currently http.Methods in the web package are checked within the functions mapped to a route and ended with an InternalServerError, if the used method is not supported for this route.

Either let the muliplexer already take care of the supported methods e.g.

r := mux.NewRouter()
r.Methods("GET", "POST").HandleFunc("/login", web.Login)

or return with the proper http.StatusMethodNotAllowed (405).

Currently the validators are just installed but not run on docker build. It might be a good idea to run them once on building the docker image to ensure that they are working as they are used by the go binary.

As an example: the usage of the nixio changed, the install succeeded, but the validation did no longer work as intended.

Currently its hardcoded to gin.g-node.org which is fine for the live service, but for development and testing purposes it would be nice to set this link via the config.

The service should feature the option to exclude a repository from validation, if its annex content is above a certain size. This avoids huge repositories spamming the storage.

The repository size should be defined via the config file.

NIX validator walks repository directory looking for NIX files. Make the walker skip .git.

The two Repository links on the Repo list page, "Repository on GIN" and "Repository hooks" link to the GIN server. We should add an external link icon (maybe 🔗?) to signify that this links offsite.

Add a button to the repository page repos/<user>/<repo>/hooks to trigger a build manually at the current HEAD. This will be useful for the first build when a user initially enables a hook and would like to test.

For each file, there should be a separate section of the results page, with the name (path) of the file prominently visible (as a title) and a separate badge for each of them.

The results page should show a history of past results. The page should show the latest results (or the "In progress" message accordingly) and on a sidebar we should have a list of the results of all the previous runs.