An error occurred fetching the project authors.
- 07 Jan, 2022 1 commit
-
-
Nicolò Maria Mezzopera authored
Add all the package managers API paths to package details type Changelog: added
-
- 06 Jan, 2022 1 commit
-
-
David Fernandez authored
This is used to differentiate package files in the pending_destruction status from the default status. Package files in the pending_destruction status are not returned by APIs/UI Changelog: other
-
- 16 Dec, 2021 1 commit
-
-
David Fernandez authored
For single package GraphQL queries. This is achieved by using: * a custom connection extension that will pass the pagination parameters to the resolver * a custom resolver that will read the pagination parameters and load the right amount of build info objects Changelog: performance
-
- 25 Nov, 2021 1 commit
-
-
Adam Hegyi authored
-
- 17 Nov, 2021 1 commit
-
-
Alex Kalderimis authored
-
- 26 Apr, 2021 1 commit
-
-
Nicolò Maria Mezzopera authored
-
- 09 Apr, 2021 1 commit
-
-
Nicolò Maria Mezzopera authored
-
- 03 Mar, 2021 1 commit
-
-
lauraMon authored
* Added max_depth or excluded pipeline when appropriate * Updates the docs
-
- 09 Feb, 2021 1 commit
-
-
Avielle Wolfe authored
New GraphQL types follow the structure of the SAST configuration types: * CiConfiguration::ApiFuzzing::ScanModeEnum * CiConfiguration::ApiFuzzing::ScanProfileType * CiConfiguration::ApiFuzzing::Type New models: * Security::ApiFuzzing::CiConfiguration * Security::ApiFuzzing::ScanProfile
-
- 01 Feb, 2021 1 commit
-
-
Alex Kalderimis authored
GraphQL does not have inheritance, so it is an anti-pattern to use it to model polymorphism in our models. The correct approach is to model polymorphism as implementation of interfaces. Here there is a single `PackageType` interface, and then different implementations of that. Since the package types only differ in their metadata, we move the polymorphism down to the metadata fields, which an empty interface, implemented by metadata types. One thing that had to change was the `Query.package` field, which was previously `Query.package_composer_details`. This must change since the implementation of the lookup does not perform any type checking, and thus we cannot type the return value as a composer package. This would be an illegal and ill-typed down-cast. A good analogy for this is having a Java collection of ```java // yes, Cucumbers are fruits - look it up List<Fruit> bowl = List.of(new Apple(), new Banana(), new Cucumber()) ``` And then expecting to get an apple without a cast: ```java Apple fruit = bowl.get(0) // bad ``` This code would fail to compile in Java, and it is equally illegal in GraphQL, without the appropriate casting. We mark the composer metadata type as an orphan since it is only refered to as an implementation of the broader metadata type. We also split the type of packages into a top-level one, which is able to refer to versions, and a leaf node which may not. This prevents unbounded mutual cyclic recursion. Return successfully for all packages We can gradually add more specific package types, but it is important to always succeed with the data we can return.
-