When there are a large number of location, `refreshAllLocations` can
emit a lot of logs that are noisy and can make debugging hard.
To solve this problem, create a child logger with a meta : `component` =
`refreshAllLocations`. That can be used to filter out logs if needed
* Feat: Create Groups plugin
* Feat: update code after CR
* Feat: change routing, replace filters to use relations, modify EntityPageLayout to support users
* Feat: update CLI version
* Feat: add some tests
* Update daily cost data to return groupedCosts
* Add aggregation sum util
* Add top panel breakdown view
* Add top panel tabs
* Add mock data for grouped Costs
* Add comments on groupedCosts
* Update wording to product in cost by product component
* Move cost overview chart legend to separate component
* Move mock data utils
* Add data viz colors for both themes
* Move mock data utils
* Update data viz dark theme colors
* Update bar chart legend type usage
* catalog-backend: gracefully handle missing codeowners
* Derive the owned entities in the catalog from group memberships
* Filter the response headers in the proxy backend
* Make backend-commons tests work on Windows
* backend: remove yarn cache from built docker image
* Refactor the hooks and also support users owning components
* backend,yarnrc: bring yarn network-timeout down to 300s
* Fix another Windows test issue
This one is a bit tricky. Instead of testing at the root folder of the drive, this test is now relative to the current directory. This resolves the difference between "/pkgs/a" and "d:\pkgs\a"
* Drop fill opacity for lighter colors
* Update dark theme colors
* Fix review comments
* techdocs-backend: update Gitlab clone auth
* Use case-insensitive filters
* Add Kubernetes plugin (#3505)
* backend-common: allow port in config to be both a number or a string
* chore: set the port as number if it comes through as a string
* Feat: Bump GitHub Insights plugin version (#3509)
* Feat: groups and components card
* Feat: update Org plugin according to CR
* Feat: update TS stuff
* Feat: change tile titles
* Feat: bump packages
* Code review fixes
Co-authored-by: Brenda Sukh <brendasukh@gmail.com>
Co-authored-by: Fredrik Adelöw <freben@gmail.com>
Co-authored-by: Dominik Henneke <dominik.henneke@sda-se.com>
Co-authored-by: Oliver Sand <oliver.sand@tentaclelabs.com>
Co-authored-by: Patrik Oldsberg <poldsberg@gmail.com>
Co-authored-by: Chongyang Adrian, Ke <ftt.adrian.ke@grabtaxi.com>
Co-authored-by: Adam Harvey <adam.harvey@dxc.com>
Co-authored-by: blam <ben@blam.sh>
Co-authored-by: Marek Calus <marek-calus@wp.pl>
Pasting a URL like `https://github.com/RoadieHQ/sample-service/blob/master/catalog-info-1.yaml`
into the Register Existing Component input creates an Entity with the
the `backstage.io/managed-by-location` annotation set to the `type` of
`url.
The TechDocs perparer does not handle this type.
```ts
switch (type) {
case 'github':
case 'gitlab':
case 'azure/api': {
// ...
}
case 'file':
// ...
default:
throw new InputError(`Unable to resolve location type ${type}`);
}
}
```
Thus, docs are never generated and we see the following error when
trying to view then in Backstage.
```
InputError: Unable to resolve location type url at DirectoryPreparer.resolveManagedByLocationToDir (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/techdocs/stages/prepare/dir.ts:63:15) at DirectoryPreparer.prepare (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/techdocs/stages/prepare/dir.ts:73:51) at DocsBuilder.build (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/service/helpers.ts:74:45) at eval (webpack-internal:///../../node_modules/@backstage/plugin-techdocs-backend/src/service/router.ts:141:25) at processTicksAndRejections (internal/process/task_queues.js:93:5)
```
This may not be the correct solution. An alternative solution would be
to ensure that pasted URLs end up with the `type` of `github` rather
than `url`.
Improve loading speed of the CI/CD page.
Only request the necessary fields from Jenkins to keep the request size low.
In addition everything is loaded in a single request, instead of requesting
each job and build individually. As this (and also the previous behavior) can
lead to a big amount of data, this limits the amount of jobs to 50.
For each job, only the latest build is loaded. Loading the full build history
of a job can lead to excessive load on the Jenkins instance.
Patrik Oldsberg