v0.38.0

@backstage/techdocs-common@0.7.0

Minor Changes

• d32d01e: Improve the annotation backstage.io/techdocs-ref: dir:<relative-target> that links to a path that is relative to the source of the annotated entity.
  This annotation works with the basic and the recommended flow, however, it will be most useful with the basic approach.

  This change remove the deprecation of the dir reference and provides first-class support for it.
  In addition, this change removes the support of the deprecated github, gitlab, and azure/api locations from the dir reference preparer.

  Example Usage

  The annotation is convenient if the documentation is stored in the same location, i.e. the same git repository, as the catalog-info.yaml.
  While it is still supported to add full URLs such as backstage.io/techdocs-ref: url:https://... for custom setups, documentation is mostly stored in the same repository as the entity definition.
  By automatically resolving the target relative to the registration location of the entity, the configuration overhead for this default setup is minimized.
  Since it leverages the @backstage/integrations package for the URL resolution, this is compatible with every supported source.

  Consider the following examples:

  1. "I have a repository with a single catalog-info.yaml and a TechDocs page in the root folder!"

     https://github.com/backstage/example/tree/main/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: example
     | > annotations:
     | > backstage.io/techdocs-ref: dir:. # -> same folder
     | > spec: {}
     |- docs/
     |- mkdocs.yml

  2. "I have a repository with a single catalog-info.yaml and my TechDocs page in located in a folder!"

     https://bitbucket.org/my-owner/my-project/src/master/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: example
     | > annotations:
     | > backstage.io/techdocs-ref: dir:./some-folder # -> subfolder
     | > spec: {}
     |- some-folder/
     |- docs/
     |- mkdocs.yml

  3. "I have a mono repository that hosts multiple components!"

     https://dev.azure.com/organization/project/_git/repository
     |- my-1st-module/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: my-1st-module
     | > annotations:
     | > backstage.io/techdocs-ref: dir:. # -> same folder
     | > spec: {}
     |- docs/
     |- mkdocs.yml
     |- my-2nd-module/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: my-2nd-module
     | > annotations:
     | > backstage.io/techdocs-ref: dir:. # -> same folder
     | > spec: {}
     |- docs/
     |- mkdocs.yml
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Location
     | > metadata:
     | > name: example
     | > spec:
     | > targets:
     | > - ./*/catalog-info.yaml

Patch Changes

• 6e5aed1: Fix validation of mkdocs.yml docs_dir
• 2509843: Add link to https://backstage.io/docs/features/techdocs/configuration in the log warning message about updating techdocs.generate key.
• Updated dependencies
  • @backstage/backend-common@0.8.7

@backstage/plugin-git-release-manager@0.2.0

Minor Changes

• a2d8922: Enable users to add custom features

  Add more metadata to success callbacks

Patch Changes

• Updated dependencies
  • @backstage/core-components@0.1.6

@backstage/plugin-techdocs-backend@0.9.0

Minor Changes

• d32d01e: Improve the annotation backstage.io/techdocs-ref: dir:<relative-target> that links to a path that is relative to the source of the annotated entity.
  This annotation works with the basic and the recommended flow, however, it will be most useful with the basic approach.

  This change remove the deprecation of the dir reference and provides first-class support for it.
  In addition, this change removes the support of the deprecated github, gitlab, and azure/api locations from the dir reference preparer.

  Example Usage

  The annotation is convenient if the documentation is stored in the same location, i.e. the same git repository, as the catalog-info.yaml.
  While it is still supported to add full URLs such as backstage.io/techdocs-ref: url:https://... for custom setups, documentation is mostly stored in the same repository as the entity definition.
  By automatically resolving the target relative to the registration location of the entity, the configuration overhead for this default setup is minimized.
  Since it leverages the @backstage/integrations package for the URL resolution, this is compatible with every supported source.

  Consider the following examples:

  1. "I have a repository with a single catalog-info.yaml and a TechDocs page in the root folder!"

     https://github.com/backstage/example/tree/main/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: example
     | > annotations:
     | > backstage.io/techdocs-ref: dir:. # -> same folder
     | > spec: {}
     |- docs/
     |- mkdocs.yml

  2. "I have a repository with a single catalog-info.yaml and my TechDocs page in located in a folder!"

     https://bitbucket.org/my-owner/my-project/src/master/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: example
     | > annotations:
     | > backstage.io/techdocs-ref: dir:./some-folder # -> subfolder
     | > spec: {}
     |- some-folder/
     |- docs/
     |- mkdocs.yml

  3. "I have a mono repository that hosts multiple components!"

     https://dev.azure.com/organization/project/_git/repository
     |- my-1st-module/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: my-1st-module
     | > annotations:
     | > backstage.io/techdocs-ref: dir:. # -> same folder
     | > spec: {}
     |- docs/
     |- mkdocs.yml
     |- my-2nd-module/
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Component
     | > metadata:
     | > name: my-2nd-module
     | > annotations:
     | > backstage.io/techdocs-ref: dir:. # -> same folder
     | > spec: {}
     |- docs/
     |- mkdocs.yml
     |- catalog-info.yaml
     | > apiVersion: backstage.io/v1alpha1
     | > kind: Location
     | > metadata:
     | > name: example
     | > spec:
     | > targets:
     | > - ./*/catalog-info.yaml

Patch Changes

• 9266b80: Implements tech docs collator to retrieve and expose search indexes for entities that have tech docs configured
• Updated dependencies
  • @backstage/techdocs-common@0.7.0
  • @backstage/catalog-client@0.3.17
  • @backstage/backend-common@0.8.7

@backstage/backend-common@0.8.7

Patch Changes

• f253572: Implement the etag functionality in the readUrl method of FetchUrlReader.

• bdd6ab5: It's possible to customize the request logging handler when building the service. For example in your backend

    const service = createServiceBuilder(module)
      .loadConfig(config)
      .setRequestLoggingHandler((logger?: Logger): RequestHandler => {
        const actualLogger = (logger || getRootLogger()).child({
          type: 'incomingRequest',
        });
        return expressWinston.logger({ ...
  

@backstage/catalog-client@0.3.17

Patch Changes

• 71c936e: Export CatalogRequestOptions type

@backstage/cli@0.7.5

Patch Changes

• 9a96b5d: chore: bump eslint to 7.30.0

@backstage/codemods@0.1.6

Patch Changes

• Updated dependencies
  • @backstage/core-components@0.1.6
  • @backstage/core-app-api@0.1.5

@backstage/core-app-api@0.1.5

Patch Changes

• ea249c6: Fix a bug in FlatRoutes that prevented outlets from working with the root route, as well as matching root routes too broadly.
• Updated dependencies
  • @backstage/core-components@0.1.6

@backstage/core-components@0.1.6

Patch Changes

• 9a751bb: Increase the vertical padding of the sidebar search input field to match the height of the parent anchor tag. This prevents users from accidentally navigating to the search page when they actually wanted to use the search input directly.
• 45b5fc3: Updated the layout of catalog and API index pages to handle smaller screen sizes. This adds responsive wrappers to the entity tables, and switches filters to a drawer when width-constrained. If you have created a custom catalog or API index page, you will need to update the page structure to match the updated catalog customization documentation.
• 03bf17...

v0.37.1

With the work coming up to remove cookiecutter as a required dependency, I've moved out the action into it's own package similar to rails-templater #6016.

By default right now it's a dependency of the scaffolder-backend so you get it automatically, but in the future it will be removed. There's also a circular dependency, which I'm not too fond of, without creating a breaking change it's hard to fix.

To compliment #6285

v0.37.0

@backstage/plugin-catalog-backend@0.13.0

Minor Changes

• 8bfc057: Add a default catalog value for BitBucketDiscoveryProcessor. This allows to have a target like so: https://bitbucket.mycompany.com/projects/backstage/repos/service-*
  which will be expanded to https://bitbucket.mycompany.com/projects/backstage/repos/service-a/catalog-info.yaml given that repository 'service-a' exists.

  Migration

  If you are using a custom Bitbucket parser and your bitbucket-discovery target (e.g. in your app-config.yaml) omits the catalog path in any of the following ways:

  • https://bitbucket.mycompany.com/projects/backstage/repos/service-*
  • https://bitbucket.mycompany.com/projects/backstage/repos/*
  • https://bitbucket.mycompany.com/projects/backstage/repos/*/

  then you will be affected by this change.
  The 'target' input to your parser before this commit would be '/', and after this commit it will be '/catalog-info.yaml', and as such needs to be handled to maintain the same functionality.

Patch Changes

• 8b04893: The codeowners processor extracts the username of the primary owner and uses this as the owner field.
  Given the kind isn't specified this is assumed to be a group and so the link to the owner in the about card
  doesn't work. This change specifies the kind where the entity is a user. e.g:

  @iain-b -> user:iain-b

• ae84b20: Revert the upgrade to fs-extra@10.0.0 as that seemed to have broken all installs inexplicably.

• Updated dependencies

  • @backstage/backend-common@0.8.6
  • @backstage/plugin-search-backend-node@0.4.0

@backstage/plugin-catalog-react@0.3.0

Minor Changes

• 976b610: Updated the software templates list page (ScaffolderPage) to use the useEntityListProvider hook from #5643. This reduces the code footprint, making it easier to customize the display of this page, and consolidates duplicate approaches to querying the catalog with filters.

  • The useEntityTypeFilter hook has been updated along with the underlying EntityTypeFilter to work with multiple values, to allow more flexibility for different user interfaces. It's unlikely that this change affects you; however, if you're using either of these directly, you'll need to update your usage.
  • SearchToolbar was renamed to EntitySearchBar and moved to catalog-react to be usable by other entity list pages
  • UserListPicker now has an availableTypes prop to restrict which user-related options to present

Patch Changes

• d84778c: Store filter values set in EntityListProvider in query parameters. This allows selected filters to be restored when returning to pages that list catalog entities.
• e13f0fb: Fix EntityTypeFilter so it produces unique case-insensitive set of available types

@backstage/plugin-jenkins@0.5.0

Minor Changes

• 6c7f00e: ## Extract an entity-oriented Jenkins Backend

  Change the Jenkins plugin from talking directly with a single Jenkins instance (via the proxy) to having a specific
  backend plugin which talks to the Jenkins instances.

  Existing users of the Jenkins plugin will need to configure a Jenkins backend instead of a proxy.
  Typically, this means creating a src/plugins/jenkins.ts file, adding a reference to it to src/index.ts and changing app-config.yaml

  jenkins.ts

  import {
    createRouter,
    DefaultJenkinsInfoProvider,
  } from '@backstage/plugin-jenkins-backend';
  import { CatalogClient } from '@backstage/catalog-client';
  import { Router } from 'express';
  import { PluginEnvironment } from '../types';
  
  export default async function createPlugin({
    logger,
    config,
    discovery,
  }: PluginEnvironment): Promise<Router> {
    const catalogClient = new CatalogClient({ discoveryApi: discovery });
  
    return await createRouter({
      logger,
      jenkinsInfoProvider: new DefaultJenkinsInfoProvider(
        catalogClient,
        config,
      ),
    });
  }

  app-config.yaml

  For example

  proxy:
    '/jenkins/api':
      target: 'https://jenkins.example.com:8080' # your Jenkins URL
      changeOrigin: true
      headers:
        Authorization: Basic ${JENKINS_BASIC_AUTH_HEADER}

  Would become:

  jenkins:
    baseUrl: https://jenkins.example.com:8080
    username: backstage-bot
    apiKey: ${JENKINS_PASSWORD}

  Change JavaScript API

  As part of the above change, the JavaScript API exposed by the plugin as a possible place for customisation has changed.
  The ApiRef now has an id of plugin.jenkins.service2 and has entity-based functions to match the endpoints exposed by
  the new backend plugin

  Change BuildWithStepsPage route

  The plugin originally provided a route to view a particular build of a particular branch so that if you wanted to view
  the master branch of an entity annotated with 'jenkins.io/github-folder': teamA/artistLookup-build you could typically
  access /catalog/default/component/artist-lookup/ci-cd/run/master/7 but would now have to access
  /catalog/default/component/artist-lookup/ci-cd/build/teamA%2FartistLookup-build%2Fmaster/7

Patch Changes

• Updated dependencies
  • @backstage/plugin-catalog-react@0.3.0

@backstage/plugin-scaffolder-backend@0.14.0

Minor Changes

• 96fc276: Updated inputs for the publish:github:pull-request action.

  Now requires a repoUrl instead of separate owner and repo inputs. This aligns with the output of the RepoUrlPicker ui field used by the pull-request sample template.

Patch Changes

• e75506f: Unsubscribe from broker after response is flushed

• ea1d956: Updating fs-extra to 10.0.0 to handle broken symbolic links correctly

• 31de5f2: Add new fetch:template action which handles the same responsibilities as fetch:cookiecutter without the external dependency on cookiecutter. For information on migrating from fetch:cookiecutter to fetch:template, see the migration guide in the docs.

• 84d329e: Scaffolder: Added an 'eq' handlebars helper for use in software template YAML files. This can be used to execute a step depending on the value of an input, e.g.:

  steps:
    id: 'conditional-step'
    action: 'custom-action'
    if: '{{ eq parameters.myvalue "custom" }}',

• ae84b20: Revert the upgrade to fs-extra@10.0.0 as that seemed to have broken all installs inexplicably.

• Updated dependencies

  • @backstage/backend-common@0.8.6

@backstage/plugin-search-backend-node@0.4.0

Minor Changes

• 97b2eb3: Change return value of SearchEngine.index to Promise<void> to support
  implementation of external search engines.

@backstage/plugin-techdocs@0.10.0

Minor Changes

• 94a54dd: Added a migrateDocsCase() method to TechDocs publishers, along with
  implementations for AWS, Azure, and GCS.

  This change is in support of a future update to TechDocs that will allow for
  case-insensitive entity triplet URL access to documentation pages which will
  require a migration of existing documentation objects in external storage
  solutions.

  See #4367 for details.

Patch Changes

• 537c37b: Fix displaying owned documents list by fetching associated entity relations
• 136a919: Show a "Refresh" button to if the content is stale.
  This removes the need to do a full page-reload to display more recent TechDocs content.
• f1200f4: Rewrite the /sync/:namespace/:kind/:name endpoint to support an event-stream as response.
  This change allows the sync process to take longer than a normal HTTP timeout.
  The stream also emits log events, so the caller can follow the build process in the frontend.
• 3af126c: Provide a Drawer component to follow a running build.
  This can be used to debug the rendering and get build logs in case an error occurs.
• 2a4a3b3: Techdocs: fix sidebars not adjusting position automatically
• Updated dependencies
  • @backstage/plugin-catalog-react@0.3.0

@backstage/plugin-user-settings@0.3.0

Minor Changes

• 71afed7: Exported and renamed components from the @backstage/plugin-user-settings plugin , to be able to use it in the consumer side and customize the SettingPage

@backstage/backend-common@0.8.6

Patch Changes

• 5f6f2fd: Support a ensureExists config option to skip ensuring a configured database exists. This allows deployment scenarios where
  limited permissions are given for provisioned databases without privileges to create new databases. If set to false, the
  database connection will not be validated prior to use which means the backend will not attempt to create the database if it
  doesn't exist. You can configure this in your app-config.yaml:

  backend:
    database:
      ensureExists: false

  This defaults to true if unspecified. You can also configure this per plugin connection and will override the base option.

• ad93bb0: Document the default behavior of statusCheck option in createStatusCheckRouter.

• ae84b20: Revert the upgrade to fs-extra@10.0.0 as that seemed to have broken all installs inexplicably.

• Updated dependencies

  • @backstage/config-loader@0.6.5

@backstage/cli@0.7.4

Patch Changes

• ae84b20: Revert the upgrade to fs-extra@10.0.0 as that seemed to have broken all installs inexplicably.
• Updated dependencies
  • @backstage/config-loader@0.6.5

@backstage/config-loader@0....

v0.36.2

Extract an entity-oriented Jenkins Backend

Originally, the jenkins plugin was frontend-only. This PR extracts a separate backend plugin with an entity-oriented API which allows the creation of a jenkins-backend plugin which provides a hook to allow Integrators to customise how jenkins instances (and the jobs for entities) are discovered.

Examples are provided and documented in the backend plugin readme

This was mainly done to focus discussion on #5518 but may also prove to be an alternative to #5016

An entity has an array of associated projects each of which has a number of builds. This is a filtered and augmented view of the upstream jenkins project and build models. This model is used as the response objects from the API but also throughout the UI.

Apart from moving some functionality into the backend, the intermediate model CITableBuildInfo (which represented a build with some project info) has been removed in favour of using Project and Build throughout.

TODO

• Support retry
• Add changesets
  • Route change for specific builds
  • New backend plugin needed (incl. config)
  • New annotation name and possible values
• Remove all ts-ignore
• config schema
• Render errors (particularly from invalid config) in UI
• update microsite
• tests

There are some more refactoring / improvement which could be done but I'm not sure if including it here would make this PR too complicated.

• rename useBuilds hook to useProjects, useBuildWithSteps to useBuild and generally make sure we are consistent with jenkins terminology
• Support an entity having multiple associated jenkins jobs
  • In router.ts and internal backend APIs generally
  • in DefaultJenkinsInfoProvider
• Support more possible jenkins layouts (in both the code in router.ts and the UI)
• Move off of the jenkins client library and just use direct REST calls.
  • The client library is <1.0 and the typings are out of date
• How do we generically reference a specific project. Currently this is entity + jobName but that doesn't scale to allow an entity to have jobs on multiple jenkins instances (build + deploy for example)

Questions

• The documentation feels a bit split across the READMEs in frontend and backend plugin, would it be better merged into one place
• I have change the id of the jenkinsApiRef. Is this needed as this is only used in the frontend plugin itself so doesn't need to be versioned particularly.
• I have included support for a simpler configuration scheme if you only have 1 instance (jenkins.baseUrl) and have described it as "deprecated" which I don't think is right as we only introduced it in this PR! How do we feel about the simplest possible config being:

jenkins:
  instances:
    - name: default
      baseUrl: https://jenkins.example.com
      username: backstage-bot
      apiKey: 123456789abcdef0123456789abcedf012

instead of:

jenkins:
  baseUrl: https://jenkins.example.com
  username: backstage-bot
  apiKey: 123456789abcdef0123456789abcedf012

The latter is more expressive but adds complexity in having to explain 2 config layouts.

• Is the route change in the UI too big a change?
• Should the frontend plugin expost an API for extensibility or is the backend ones enough?

closes #5016 #5518

v0.36.1

XCMetrics Plugin

This is a first version of the XCMetrics plugin which shows the latest (the backend defaults to 10) builds from a XCMetrics backend instance in a table.

The plugin includes the components for rendering and an API client which calls XCMetrics through the proxy.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

v0.36.0

@backstage/catalog-model@0.9.0

Minor Changes

• 77db0c4: Changed the regex to validate names following the Kubernetes validation rule, this allow to be more permissive validating the name of the object in Backstage.

• 60e8302: Support for Template kinds with version backstage.io/v1alpha1 has now been removed. This means that the old method of running templates with Preparers, Templaters and Publishers has also been removed. If you had any logic in these abstractions, they should now be moved to actions instead, and you can find out more about those in the documentation

  If you need any help migrating existing templates, there's a migration guide. Reach out to us on Discord in the #support channel if you're having problems.

  The scaffolder-backend now no longer requires these Preparers, Templaters, and Publishers to be passed in, now all it needs is the containerRunner.

  Please update your packages/backend/src/plugins/scaffolder.ts like the following

  - import {
  -  DockerContainerRunner,
  -  SingleHostDiscovery,
  - } from '@backstage/backend-common';
  + import { DockerContainerRunner } from '@backstage/backend-common';
    import { CatalogClient } from '@backstage/catalog-client';
  - import {
  -   CookieCutter,
  -   CreateReactAppTemplater,
  -   createRouter,
  -   Preparers,
  -   Publishers,
  -   Templaters,
  - } from '@backstage/plugin-scaffolder-backend';
  + import { createRouter } from '@backstage/plugin-scaffolder-backend';
    import Docker from 'dockerode';
    import { Router } from 'express';
    import type { PluginEnvironment } from '../types';
  
    export default async function createPlugin({
      config,
      database,
      reader,
  +   discovery,
    }: PluginEnvironment): Promise<Router> {
      const dockerClient = new Docker();
      const containerRunner = new DockerContainerRunner({ dockerClient });
  
  -   const cookiecutterTemplater = new CookieCutter({ containerRunner });
  -   const craTemplater = new CreateReactAppTemplater({ containerRunner });
  -   const templaters = new Templaters();
  
  -   templaters.register('cookiecutter', cookiecutterTemplater);
  -   templaters.register('cra', craTemplater);
  -
  -   const preparers = await Preparers.fromConfig(config, { logger });
  -   const publishers = await Publishers.fromConfig(config, { logger });
  
  -   const discovery = SingleHostDiscovery.fromConfig(config);
      const catalogClient = new CatalogClient({ discoveryApi: discovery });
  
      return await createRouter({
  -     preparers,
  -     templaters,
  -     publishers,
  +     containerRunner,
        logger,
        config,
        database,
  

@backstage/plugin-catalog-backend@0.12.0

Minor Changes

• 60e8302: Support for Template kinds with version backstage.io/v1alpha1 has now been removed. This means that the old method of running templates with Preparers, Templaters and Publishers has also been removed. If you had any logic in these abstractions, they should now be moved to actions instead, and you can find out more about those in the documentation

  If you need any help migrating existing templates, there's a migration guide. Reach out to us on Discord in the #support channel if you're having problems.

  The scaffolder-backend now no longer requires these Preparers, Templaters, and Publishers to be passed in, now all it needs is the containerRunner.

  Please update your packages/backend/src/plugins/scaffolder.ts like the following

  - import {
  -  DockerContainerRunner,
  -  SingleHostDiscovery,
  - } from '@backstage/backend-common';
  + import { DockerContainerRunner } from '@backstage/backend-common';
    import { CatalogClient } from '@backstage/catalog-client';
  - import {
  -   CookieCutter,
  -   CreateReactAppTemplater,
  -   createRouter,
  -   Preparers,
  -   Publishers,
  -   Templaters,
  - } from '@backstage/plugin-scaffolder-backend';
  + import { createRouter } from '@backstage/plugin-scaffolder-backend';
    import Docker from 'dockerode';
    import { Router } from 'express';
    import type { PluginEnvironment } from '../types';
  
    export default async function createPlugin({
      config,
      database,
      reader,
  +   discovery,
    }: PluginEnvironment): Promise<Router> {
      const dockerClient = new Docker();
      const containerRunner = new DockerContainerRunner({ dockerClient });
  
  -   const cookiecutterTemplater = new CookieCutter({ containerRunner });
  -   const craTemplater = new CreateReactAppTemplater({ containerRunner });
  -   const templaters = new Templaters();
  
  -   templaters.register('cookiecutter', cookiecutterTemplater);
  -   templaters.register('cra', craTemplater);
  -
  -   const preparers = await Preparers.fromConfig(config, { logger });
  -   const publishers = await Publishers.fromConfig(config, { logger });
  
  -   const discovery = SingleHostDiscovery.fromConfig(config);
      const catalogClient = new CatalogClient({ discoveryApi: discovery });
  
      return await createRouter({
  -     preparers,
  -     templaters,
  -     publishers,
  +     containerRunner,
        logger,
        config,
        database,
  

Patch Changes

• f7134c3: bump sqlite3 to 5.0.1
• 6841e01: fix minor version of git-url-parse as 11.5.x introduced a bug for Bitbucket Server
• 2d41b69: Make use of the new readUrl method on UrlReader from @backstage/backend-common.
• Updated dependencies
  • @backstage/integration@0.5.8
  • @backstage/catalog-model@0.9.0
  • @backstage/backend-common@0.8.5
  • @backstage/plugin-search-backend-node@0.3.0
  • @backstage/catalog-client@0.3.16

@backstage/plugin-catalog-backend-module-ldap@0.2.0

Minor Changes

• b055ef8: Add extension points to the LdapOrgReaderProcessor to make it possible to do more advanced modifications
  of the ingested users and groups.

Patch Changes

• Updated dependencies
  • @backstage/catalog-model@0.9.0
  • @backstage/plugin-catalog-backend@0.12.0

@backstage/plugin-scaffolder@0.10.0

Minor Changes

• 60e8302: Support for Template kinds with version backstage.io/v1alpha1 has now been removed. This means that the old method of running templates with Preparers, Templaters and Publishers has also been removed. If you had any logic in these abstractions, they should now be moved to actions instead, and you can find out more about those in the documentation

  If you need any help migrating existing templates, there's a migration guide. Reach out to us on Discord in the #support channel if you're having problems.

  The scaffolder-backend now no longer requires these Preparers, Templaters, and Publishers to be passed in, now all it needs is the containerRunner.

  Please update your packages/backend/src/plugins/scaffolder.ts like the following

  - import {
  -  DockerContainerRunner,
  -  SingleHostDiscovery,
  - } from '@backstage/backend-common';
  + import { DockerContainerRunner } from '@backstage/backend-common';
    import { CatalogClient } from '@backstage/catalog-client';
  - import {
  -   CookieCutter,
  -   CreateReactAppTemplater,
  -   createRouter,
  -   Preparers,
  -   Publishers,
  -   Templaters,
  - } from '@backstage/plugin-scaffolder-backend';
  + import { createRouter } from '@backstage/plugin-scaffolder-backend';
    import Docker from 'dockerode';
    import { Router } from 'express';
    import type { PluginEnvironment } from '../types';
  
    export default async function createPlugin({
      config,
      database,
      reader,
  +   discovery,
    }: PluginEnvironment): Promise<Router> {
      const dockerClient = new Docker();
      const containerRunner = new DockerContainerRunner({ dockerClient });
  
  -   const cookiecutterTemplater = new CookieCutter({ containerRunner });
  -   const craTemplater = new CreateReactAppTemplater({ containerRunner });
  -   const templaters = new Templaters();
  
  -   templaters.register('cookiecutter', cookiecutterTemplater);
  -   templaters.register('cra', craTemplater);
  -
  -   const preparers = await Preparers.fromConfig(config, { logger });
  -   const publishers = await Publishers.fromConfig(config, { logger });
  
  -   const discovery = SingleHostDiscovery.fromConfig(config);
      const catalogClient = new CatalogClient({ discoveryApi: discovery });
  
      return await createRouter({
  -     preparers,
  -     templaters,
  -     publishers,
  +     containerRunner,
        logger,
        config,
        database,
  

Patch Changes

• 02b9623: Added a context parameter to validator functions, letting them have access to
  the API holder.

  If you have implemented custom validators and use createScaffolderFieldExtension,
  your validation function can now optionally accept a third parameter,
  context: { apiHolder: ApiHolder }.

• 6841e01: fix minor version of git-url-parse as 11.5.x introduced a bug for Bitbucket Server

• 0adfae5: add support for uiSchema on dependent form fields

• bd764f7: Pass through the idToken i...

v0.35.1

Hey, I just made a Pull Request!

I created a module for Rails and one action to use rails new in the scaffolder

Addesd to the plugin list:

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

v0.35.0

@backstage/plugin-catalog-backend@0.11.0

Minor Changes

• 45af985: Handle entity name conflicts in a deterministic way and avoid crashes due to naming conflicts at startup.

  This is a breaking change for the database and entity provider interfaces of the new catalog. The interfaces with breaking changes are EntityProvider and ProcessingDatabase, and while it's unlikely that these interfaces have much usage yet, a migration guide is provided below.

  The breaking change to the EntityProvider interface lies within the items passed in the EntityProviderMutation type. Rather than passing along entities directly, they are now wrapped up in a DeferredEntity type, which is a tuple of an entity and a locationKey. The entity houses the entity as it was passed on before, while the locationKey is a new concept that is used for conflict resolution within the catalog.

  The locationKey is an opaque string that should be unique for each location that an entity could be located at, and undefined if the entity does not have a fixed location. In practice it should be set to the serialized location reference if the entity is stored in Git, for example https://github.com/backstage/backstage/blob/master/catalog-info.yaml. A conflict between two entity definitions happen when they have the same entity reference, i.e. kind, namespace, and name. In the event of a conflict the location key will be used according to the following rules to resolve the conflict:

  • If the entity is already present in the database but does not have a location key set, the new entity wins and will override the existing one.
  • If the entity is already present in the database the new entity will only win if the location keys of the existing and new entity are the same.
  • If the entity is not already present, insert the entity into the database along with the provided location key.

  The breaking change to the ProcessingDatabase is similar to the one for the entity provider, as it reflects the switch from Entity to DeferredEntity in the ReplaceUnprocessedEntitiesOptions. In addition, the addUnprocessedEntities method has been removed from the ProcessingDatabase interface, and the RefreshStateItem and UpdateProcessedEntityOptions types have received a new optional locationKey property.

• 8e533f9: Move LdapOrgReaderProcessor from @backstage/plugin-catalog-backend
  to @backstage/plugin-catalog-backend-module-ldap.

  The LdapOrgReaderProcessor isn't registered by default anymore, if
  you want to continue using it you have to register it manually at the catalog
  builder:

  1. Add dependency to @backstage/plugin-catalog-backend-module-ldap to the package.json of your backend.
  2. Add the processor to the catalog builder:

  // packages/backend/src/plugins/catalog.ts
  builder.addProcessor(
    LdapOrgReaderProcessor.fromConfig(config, {
      logger,
    }),
  );

  For more configuration details, see the README of the @backstage/plugin-catalog-backend-module-ldap package.

Patch Changes

• 22a6051: Support ingesting multiple GitHub organizations via a new GithubMultiOrgReaderProcessor.

  This new processor handles namespacing created groups according to the org of the associated GitHub team to prevent potential name clashes between organizations. Be aware that this processor is considered alpha and may not be compatible with future org structures in the catalog.

  NOTE: This processor only fully supports auth via GitHub Apps

  To install this processor, import and add it as follows:

  // Typically in packages/backend/src/plugins/catalog.ts
  import { GithubMultiOrgReaderProcessor } from '@backstage/plugin-catalog-backend';
  // ...
  export default async function createPlugin(env: PluginEnvironment) {
    const builder = new CatalogBuilder(env);
    builder.addProcessor(
      GithubMultiOrgReaderProcessor.fromConfig(env.config, {
        logger: env.logger,
      }),
    );
    // ...
  }

  Configure in your app-config.yaml by pointing to your GitHub instance and optionally list which GitHub organizations you wish to import. You can also configure what namespace you want to set for teams from each org. If unspecified, the org name will be used as the namespace. If no organizations are listed, by default this processor will import from all organizations accessible by all configured GitHub Apps:

  catalog:
    locations:
      - type: github-multi-org
        target: https://github.myorg.com
  
    processors:
      githubMultiOrg:
        orgs:
          - name: fooOrg
            groupNamespace: foo
          - name: barOrg
            groupNamespace: bar
          - name: awesomeOrg
          - name: anotherOrg

• d408af8: Only return the selected fields from the new catalog.

• aa2b15d: Ensure that emitted relations are deduplicated

• Updated dependencies

  • @backstage/backend-common@0.8.4
  • @backstage/integration@0.5.7
  • @backstage/catalog-client@0.3.15

@backstage/plugin-catalog-backend-module-msgraph@0.2.0

Minor Changes

• 115473c: Handle error gracefully if failure occurs while loading photos using Microsoft Graph API.

  This includes a breaking change: you now have to pass the options object to readMicrosoftGraphUsers and readMicrosoftGraphOrg.

Patch Changes

• Updated dependencies
  • @backstage/plugin-catalog-backend@0.11.0

@backstage/backend-common@0.8.4

Patch Changes

• 88d742e: Download archives as compressed tar files for GitLab to fix the readTree bug in TODO Plugin.
• ab5cc37: Add new isChildPath and resolveSafeChildPath exports
• Updated dependencies
  • @backstage/cli-common@0.1.2
  • @backstage/integration@0.5.7

@backstage/catalog-client@0.3.15

Patch Changes

• ca080ca: Don't crash if the entities response doesn't include the entities name and kind

@backstage/cli@0.7.3

Patch Changes

• a93e60f: Updated dependencies
• 55f49fc: Update dependencies
• ab5cc37: Use new isChildPath export from @backstage/cli-common
• Updated dependencies
  • @backstage/cli-common@0.1.2

@backstage/cli-common@0.1.2

Patch Changes

• ab5cc37: Add new isChildPath export

@backstage/codemods@0.1.4

Patch Changes

• Updated dependencies
  • @backstage/core-app-api@0.1.4
  • @backstage/core-components@0.1.4
  • @backstage/cli-common@0.1.2

@backstage/core-app-api@0.1.4

Patch Changes

• 62abffe: Reintroduce export of defaultConfigLoader.
• Updated dependencies
  • @backstage/core-components@0.1.4

@backstage/core-components@0.1.4

Patch Changes

• f423891: Fixed sizing of the System diagram when the rendered graph was wider than the container.

• 3db266f: Make ErrorBoundary display more helpful information about the error that
  occurred.

  The slackChannel (optional) prop can now be passed as an object on the form
  { name: string; href?: string; } in addition to the old string form. If you
  are using the error boundary like

  <ErrorBoundary slackChannel="#support">
    <InnerComponent>
  </ErrorBoundary>

  you may like to migrate it to

  const support = {
    name: '#support',
    href: 'https://slack.com/channels/your-channel',
  };
  
  <ErrorBoundary slackChannel={support}>
    <InnerComponent>
  </ErrorBoundary>

  Also deprecated the prop slackChannel on TabbedCard and InfoCard, while
  adding the prop errorBoundaryProps to replace it.

• e8c65b0: Clear the previously selected sign-in provider on failure

@backstage/create-app@0.3.29

Patch Changes

• Updated dependencies
  • @backstage/cli-common@0.1.2

@backstage/integration@0.5.7

Patch Changes

• 22a6051: Support ingesting multiple GitHub organizations via a new GithubMultiOrgReaderProcessor.

  This new processor handles namespacing created groups according to the org of the associated GitHub team to prevent potential name clashes between organizations. Be aware that this processor is considered alpha and may not be compatible with future org structures in the catalog.

  NOTE: This processor only fully supports auth via GitHub Apps

  To install this processor, import and add it as follows:

  // Typically in packages/backend/src/plugins/catalog.ts
  import { GithubMultiOrgReaderProcessor } from '@backstage/plugin-catalog-backend';
  // ...
  export default async function createPlugin(env: PluginEnvironment) {
    const builder = new CatalogBuilder(env);
    builder.addProcessor(
      GithubMultiOrgReaderProcessor.fromConfig(env.config, {
        logger: env.logger,
      }),
    );
    // ...
  }

  Configure in your app-config.yaml by pointing to your GitHub instance and optionally list which GitHub organizations you wish to import. You can also configure what namespace you want to set for teams from each org. If unspecified, the org name will be used as the namespace. If no organizations are listed, by default this processor will import from all organizations accessible by all configured GitHub Apps:

  catalog:
    locations:
      - type: github-multi-org
        target: https://github.myorg.com
  
    processors:
      githubMultiOrg:
        orgs:
          - name: fooOrg
            groupNamespace: foo
          - name: barOrg
            groupNamespace: bar
          - name: awesomeOrg
          - name: anotherOrg

@backstage/techdocs-common@0.6.6

Patch Changes

• ab5cc37: Use ne...

v0.34.1

Signed-off-by: Mathias Åhsberg mathias.ahsberg@resurs.se

Hey, I just made a Pull Request!

This pull request is heavily inspired by the extraction of the MicrosoftGraph processor in #5854 and follows the same pattern.

The final goal is to add support for customized transformers just as the MicrosoftGraph processor. However, To make it easier to review I want to split it into two separate parts.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

v0.34.0

@backstage/dev-utils@0.2.0

Minor Changes

• 76db86c: Removed support for deprecated registered plugin routes. All routes now need to be added using addPage instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-app-api@0.1.3
  • @backstage/core-plugin-api@0.1.3
  • @backstage/catalog-model@0.8.4
  • @backstage/integration-react@0.1.4
  • @backstage/test-utils@0.1.14
  • @backstage/plugin-catalog-react@0.2.4

@backstage/plugin-api-docs@0.6.0

Minor Changes

• d719926: BREAKING CHANGE Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• 7bd46b1: Move EntityTypePicker to be consistent with CatalogPage and remove api: prefix from entity names
• Updated dependencies
  • @backstage/plugin-catalog@0.6.4
  • @backstage/core-plugin-api@0.1.3
  • @backstage/catalog-model@0.8.4
  • @backstage/plugin-catalog-react@0.2.4

@backstage/plugin-cost-insights@0.11.0

Minor Changes

• d719926: BREAKING CHANGE Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/plugin-gcp-projects@0.3.0

Minor Changes

• d719926: BREAKING CHANGE Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/plugin-gitops-profiles@0.3.0

Minor Changes

• d719926: BREAKING CHANGE Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/plugin-newrelic@0.3.0

Minor Changes

• d719926: BREAKING CHANGE Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/plugin-welcome@0.3.0

Minor Changes

• d719926: BREAKING CHANGE Remove deprecated route registrations, meaning that it is no longer enough to only import the plugin in the app and the exported page extension must be used instead.

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/catalog-client@0.3.14

Patch Changes

• 45ef515: Return entities sorted alphabetically by ref
• Updated dependencies
  • @backstage/catalog-model@0.8.4

@backstage/catalog-model@0.8.4

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.

@backstage/cli@0.7.2

Patch Changes

• 953a7e6: updated plugin template to generate path equals plugin id for the root page
• 04248b8: chore: bump msw dependency in create-plugin
• e3d31b3: Make the create-github-app command disable webhooks by default.
• 8f100db: chore: bump @typescript-eslint/eslint-plugin from 4.26.0 to 4.27.0
• 95e5723: chore: bump del from 5.1.0 to 6.0.0
• ece2b5d: chore: bump @spotify/eslint-config-typescript from 9.0.0 to 10.0.0
• 0ec31e5: chore: bump @rollup/plugin-node-resolve from 11.2.1 to 13.0.0
• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.

@backstage/codemods@0.1.3

Patch Changes

• Updated dependencies
  • @backstage/core-app-api@0.1.3
  • @backstage/core-plugin-api@0.1.3

@backstage/core@0.7.14

Patch Changes

• a1c30d7: Add deprecation warning to package README.
• Updated dependencies
  • @backstage/core-api@0.2.23

@backstage/core-api@0.2.23

Patch Changes

• a1c30d7: Add deprecation warning to package README.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/core-app-api@0.1.3

Patch Changes

• dc3e7ce: Introducing new UnhandledErrorForwarder installed by default. For catching unhandled promise rejections, you can override the API to align with general error handling.
• 5f4339b: Adding FeatureFlag component and treating FeatureFlags as first class citizens to composability API
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/core-plugin-api@0.1.3

Patch Changes

• 5f4339b: Adding FeatureFlag component and treating FeatureFlags as first class citizens to composability API

@backstage/create-app@0.3.28

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.

@backstage/integration-react@0.1.4

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3

@backstage/techdocs-common@0.6.5

Patch Changes

• c17c0fc: Adding additional checks on tech docs to prevent folder traversal via mkdocs.yml docs_dir value.
• Updated dependencies
  • @backstage/catalog-model@0.8.4

@backstage/test-utils@0.1.14

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-app-api@0.1.3
  • @backstage/core-plugin-api@0.1.3

@backstage/plugin-auth-backend@0.3.14

Patch Changes

• 36e9a40: Don't export the defaultGoogleAuthProvider

• c467cc4: Adds support for custom sign-in resolvers and profile transformations for the
  Google auth provider.

  Adds an ent claim in Backstage tokens, with a list of
  entity references
  related to your signed-in user's identities and groups across multiple systems.

  Adds an optional providerFactories argument to the createRouter exported by
  the auth-backend plugin.

  Updates BackstageIdentity so that

  • idToken is deprecated in favor of token
  • An optional entity field is added which represents the entity that the user is represented by within Backstage.

  More information:

  • The identity resolver documentation
    explains the concepts and shows how to implement your own.
  • The From Identity to Ownership
    RFC contains details about how this affects ownership in the catalog

• Updated dependencies

  • @backstage/catalog-client@0.3.14
  • @backstage/catalog-model@0.8.4
  • @backstage/test-utils@0.1.14

@backstage/plugin-badges@0.2.3

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3
  • @backstage/catalog-model@0.8.4
  • @backstage/plugin-catalog-react@0.2.4

@backstage/plugin-bitrise@0.1.5

Patch Changes

• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3
  • @backstage/catalog-model@0.8.4
  • @backstage/plugin-catalog-react@0.2.4

@backstage/plugin-catalog@0.6.4

Patch Changes

• bba9df7: improve the wrapping behavior of long entity links
• 5f4339b: Adding FeatureFlag component and treating FeatureFlags as first class citizens to composability API
• 7bd46b1: Allow defaultKind from CatalogTable.column.creatNameColumn to be configurable
• 71416fb: Moved installation instructions from the main backstage.io documentation to the package README file. These instructions are not generally needed, since the plugin comes installed by default with npx @backstage/create-app.
• e3cbfa8: Disambiguated titles of EntityDependencyOfComponentsCard and EntityDependsOnComponentsCard.
• 3d7b1c9: Adds an optional actions prop to CatalogTable and CatalogPage to support supplying custom actions for each entity row in the table. This uses the default actions if not provided.
• 48c9fcd: Migrated to use the new @backstage/core-* packages rather than @backstage/core.
• 80a82ff: Clearer titles for the relationship cards
• Updated dependencies
  • @backstage/core-plugin-api@0.1.3
  • @backstage/catalog-client@0.3.14
  • @backstage/catalog-model@0.8.4
  • @backstage/integration-react@0.1.4
  • @backstage/plugin-catalog-react@0.2.4

@backstage/plugin-catalog-backend@0.10.4

Patch Changes

• 127048f: Move MicrosoftGraphOrgReaderProcessor from @backstage/plugin-catalog-backend
  to @backstage/plugin-catalog-backend-module-msgraph.

  The MicrosoftGraphOrgReaderProcessor isn't registered by default anymor...