43160dcc43
We encountered some problems with using the existing folder structure, but it looks like running the tooling with the latest versions works after we regenerated the project using 'gql init' and refactoring to separate the login previously in resolvers.go. - the autogenerated code is now under the gql_generated folder - the file resolvers.go now contains only the code which is not rewritten by the gqlgen framework - the file schema.resolvers.go is rewritten when gqlgen runs, and we'll only keep there the actual resolvers matching query names Changes we observed to schema.resolvers.go when gqlgen runs include reordering methods, and renaming function parameters to match the names used in schema.graphql - we now have a gqlgen.yaml config file which governs the behavior of gqlgen (can be tweaked to restructure the folder structure of the generated code in the future) Looks like the new graphql server has better validation 1 Returns 422 instead of 200 for missing query string - had to update tests 2 Correctly uncovered an error in a test for a bad `%` in query string. As as result of 2, a `masked` bug was found in the way we check if images are signed with Notary, the signatures were reasched for with the media type of the image manifest itself instead of the media type for notation. Fixed this bug, and improved error messages. This bug would have also been reproducible with main branch if the bad `%` in the test would have fixed. Updated the linter to ignore some issues with the code which is always rewritten when running: `go run github.com/99designs/gqlgen@v0.17.13 generate` Add a workflow to test gqlgen works and has no uncommitted changes Signed-off-by: Andrei Aaron <andaaron@cisco.com> |
||
|---|---|---|
| .. | ||
| config | ||
| monitoring | ||
| scrub | ||
| search | ||
| sync | ||
| _zot.md | ||
| extension-metrics-disabled.go | ||
| extension-metrics.go | ||
| extension-scrub-disabled.go | ||
| extension-scrub.go | ||
| extension-search-disabled.go | ||
| extension-search.go | ||
| extension-sync-disabled.go | ||
| extension-sync.go | ||
| extensions_test.go | ||
| README.md | ||
Adding new extensions
As new requirements come and build time extensions need to be added, there are a few things that you have to make sure are present before commiting :
- files that should be included in the binary only with a specific extension must contain the following syntax at the beginning of the file :
//go:build sync will be added automatically by the linter, so only the second line is mandatory .
NOTE: the third line in the example should be blank, otherwise the build tag would be just another comment.
//go:build sync
// +build sync
package extensions
...................
-
when adding a new tag, specify the new order in which multiple tags should be used (bottom of this page)
-
for each and every new file that contains functions (functionalities) specific to an extension, one should create a corresponding file that must contain the exact same functions, but no functionalities included. This file must begin with an "anti-tag" (e.g. // +build !sync) which will include this file in binaries that don't include this extension ( in this example, the file won't be used in binaries that include sync extension ). See extension-sync-disabled.go for an example.
-
when a new extension comes out, the developer should also write some blackbox tests, where a binary that contains the new extension should be tested in a real usage scenario. See test/blackbox folder for multiple extensions examples.
-
newly added blackbox tests should have targets in Makefile. You should also add them as Github Workflows, in .github/workflows/ecosystem-tools.yaml
-
with every new extension, you should modify the EXTENSIONS variable in Makefile by adding the new extension. The EXTENSIONS variable represents all extensions and is used in Make targets that require them all (e.g make test).
-
the available extensions that can be used at the moment are: sync, scrub, metrics, search, ui_base . NOTE: When multiple extensions are used, they should be enlisted in the above presented order.