Merge branch 'master' into doc-custom-template-filter
Signed-off-by: Charles Moulliard <cmoulliard@redhat.com>
This commit is contained in:
Charles Moulliard
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-common': patch
|
||||
'@backstage/plugin-scaffolder-react': patch
|
||||
'@backstage/plugin-scaffolder': patch
|
||||
---
|
||||
|
||||
Capturing more event clicks for scaffolder
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-node': minor
|
||||
---
|
||||
|
||||
Added `LocationAnalyzer` type, moved from `@backstage/plugin-catalog-backend`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Allow overriding `NotificationsPage` page properties
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Add lifecycle monitoring for the catalog processing
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-msgraph': patch
|
||||
---
|
||||
|
||||
Fixed disabling of user photo fetching. Previously, the config value wasn't propagated properly, so user photos was still being fetched despite disabled by config.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
---
|
||||
|
||||
Fix issue with the log format not being respected when logging from actions
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gitea': patch
|
||||
---
|
||||
|
||||
Allow defining `repoVisibility` field for the action `publish:gitea`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/create-app': patch
|
||||
---
|
||||
|
||||
Bumped create-app version.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/repo-tools': patch
|
||||
---
|
||||
|
||||
Update the paths logic in the api reports command to support complex subpaths
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-notifications-backend-module-email': patch
|
||||
'@backstage/plugin-notifications-backend': patch
|
||||
---
|
||||
|
||||
Fixed email processor `esm` issue and config reading
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-unprocessed': patch
|
||||
---
|
||||
|
||||
Correctly convert owner to string in case owner has not been provided
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': minor
|
||||
---
|
||||
|
||||
Deprecated the `LocationAnalyzer` type, which has been moved to `@backstage/plugin-catalog-node`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Added `HarnessURLReader` with `readUrl` support.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-incremental-ingestion': patch
|
||||
---
|
||||
|
||||
Fix plugin/incremental-ingestion 'Maximum call stack size exceeded' error when ingest large entities.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/repo-tools': minor
|
||||
---
|
||||
|
||||
Adds 2 new commands `repo schema openapi diff` and `package schema openapi diff`. `repo schema openapi diff` is intended to power a new breaking changes check on pull requests and the package level command allows plugin developers to quickly see new API breaking changes. They're intended to be used in complement with the existing `repo schema openapi verify` command to validate your OpenAPI spec against a variety of things.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-notifications-backend': patch
|
||||
'@backstage/plugin-notifications-node': patch
|
||||
---
|
||||
|
||||
Support for filtering entities from notification recipients after resolving them from the recipients
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
The user can newly mark all unread messages as read at one click.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Fixed an internal circular import that broke Jest mocks.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications-backend-module-email': patch
|
||||
---
|
||||
|
||||
Support relative links in notifications sent via email
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications-backend-module-email': patch
|
||||
---
|
||||
|
||||
Allow sending notifications by email with the new notifications module
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-devtools-backend': patch
|
||||
---
|
||||
|
||||
Added discovery property to the readme documentation to ensure that it will build when setting it up as new to a Backstage instance
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': minor
|
||||
---
|
||||
|
||||
The `/alpha` plugin export has had its implementation of the `catalogAnalysisExtensionPoint` updated to reflect the new API.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-common': patch
|
||||
---
|
||||
|
||||
Added config prop `ensureSchemaExists` to support postgres instances where user can create schemas but not databases.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Allow showing notifications as snackbars in the UI
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend': patch
|
||||
'@backstage/backend-app-api': patch
|
||||
---
|
||||
|
||||
Redact `meta` fields too with the logger
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
The `versions:bump` command will no longer exit with a non-zero status if the version bump fails due to forbidden duplicate package installations. It will now also provide more information about how to troubleshoot such an error. The set of forbidden duplicates has also been expanded to include all `@backstage/*-app-api` packages.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend-node': patch
|
||||
'@backstage/plugin-search-backend': patch
|
||||
---
|
||||
|
||||
Add lifecycle monitoring for the search index registry
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/plugin-auth-backend-module-aws-alb-provider': patch
|
||||
'@backstage/plugin-auth-backend-module-github-provider': patch
|
||||
'@backstage/plugin-auth-backend': patch
|
||||
---
|
||||
|
||||
fix: Move config declarations to appropriate auth backend modules
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/backend-app-api': patch
|
||||
---
|
||||
|
||||
Remove explicit `alg` check for user tokens in `verifyToken`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-auth-react': patch
|
||||
---
|
||||
|
||||
When using `CookieAuthRefreshProvider` or `useCookieAuthRefresh`, a 404 response from the cookie endpoint will now be treated as if cookie auth is disabled and is not needed.
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'@backstage/backend-common': minor
|
||||
---
|
||||
|
||||
Internal refactor of the database code.
|
||||
|
||||
**BREAKING**: The helper functions `createDatabaseClient` and `ensureDatabaseExists` have been removed from the public interface, since they have no usage within the repository and never were suitable for calling from the outside. Please consider using `coreServices.database` or `DatabaseManager` directly wherever possible instead.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Increase default and allow modifying notification snackbar auto hide duration
|
||||
+71
-2
@@ -281,7 +281,76 @@
|
||||
"@backstage/plugin-vault": "0.1.29",
|
||||
"@backstage/plugin-vault-backend": "0.4.10",
|
||||
"@backstage/plugin-vault-node": "0.1.10",
|
||||
"@backstage/plugin-xcmetrics": "0.2.52"
|
||||
"@backstage/plugin-xcmetrics": "0.2.52",
|
||||
"@backstage/plugin-catalog-backend-module-gitlab-org": "0.0.0",
|
||||
"@backstage/plugin-notifications-backend-module-email": "0.0.0"
|
||||
},
|
||||
"changesets": []
|
||||
"changesets": [
|
||||
"afraid-needles-divide",
|
||||
"blue-hotels-shake",
|
||||
"bright-pumpkins-rule",
|
||||
"chatty-cycles-unite",
|
||||
"chilly-adults-sing",
|
||||
"chilly-fireants-roll",
|
||||
"chilly-shoes-doubt",
|
||||
"cold-rats-leave",
|
||||
"cool-elephants-march",
|
||||
"create-app-1714476054",
|
||||
"cuddly-chairs-kick",
|
||||
"curly-shirts-flow",
|
||||
"curvy-planes-flash",
|
||||
"cyan-suns-shave",
|
||||
"dry-sloths-impress",
|
||||
"eighty-apricots-kneel",
|
||||
"eighty-bats-stare",
|
||||
"eleven-pandas-divide",
|
||||
"fix-stackoverflow",
|
||||
"fluffy-hotels-wait",
|
||||
"four-cooks-serve",
|
||||
"fresh-crews-impress",
|
||||
"funny-bees-taste",
|
||||
"fuzzy-seahorses-tell",
|
||||
"gold-waves-bake",
|
||||
"gorgeous-cameras-cross",
|
||||
"green-adults-push",
|
||||
"green-boxes-rescue",
|
||||
"hip-carrots-drive",
|
||||
"hot-forks-train",
|
||||
"itchy-gorillas-hope",
|
||||
"itchy-keys-wonder",
|
||||
"late-planes-fix",
|
||||
"loud-frogs-eat",
|
||||
"loud-timers-flow",
|
||||
"loud-vans-greet",
|
||||
"lovely-games-cry",
|
||||
"lucky-news-guess",
|
||||
"mean-ravens-dance",
|
||||
"orange-numbers-think",
|
||||
"perfect-points-hope",
|
||||
"proud-doors-cheat",
|
||||
"purple-parents-sin",
|
||||
"purple-waves-smile",
|
||||
"rare-fireants-tickle",
|
||||
"real-crabs-obey",
|
||||
"renovate-0d0bd5c",
|
||||
"selfish-pigs-glow",
|
||||
"shy-students-clap",
|
||||
"silent-wombats-hang",
|
||||
"six-scissors-smile",
|
||||
"smart-avocados-invent",
|
||||
"smooth-garlics-behave",
|
||||
"sour-socks-approve",
|
||||
"stupid-onions-know",
|
||||
"sweet-zoos-clap",
|
||||
"tall-ads-shave",
|
||||
"tasty-apes-learn",
|
||||
"thick-llamas-itch",
|
||||
"thick-terms-rush",
|
||||
"tricky-cougars-shout",
|
||||
"unlucky-days-play",
|
||||
"unlucky-rivers-collect",
|
||||
"warm-fans-promise",
|
||||
"young-guests-reflect",
|
||||
"young-olives-drop"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Added optional `initialShowDropDown` prop to `SidebarSubmenuItem` to internally manage the initial display state of the dropdown items.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search-backend-module-explore': patch
|
||||
---
|
||||
|
||||
Migrate search collator to use the new auth services.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-github': patch
|
||||
---
|
||||
|
||||
Updated to use the new `catalogAnalysisExtensionPoint` API.
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/plugin-auth-backend': patch
|
||||
'@backstage/plugin-auth-node': patch
|
||||
---
|
||||
|
||||
Allow overriding default ownership resolving with the new `AuthOwnershipResolutionExtensionPoint`
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
Add `alignGauge` prop to the `GaugeCard`, and a small size version. When `alignGauge` is `'bottom'` the gauge will vertically align the gauge in the cards, even when the card titles span across multiple lines.
|
||||
Add `alignContent` prop to the `InfoCard`, defaulting to `'normal'` with the option of `'bottom'` which vertically aligns the content to the bottom of the card.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend-module-msgraph': patch
|
||||
---
|
||||
|
||||
Handle fetching huge amounts of users from Azure without crashing
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/core-components': patch
|
||||
---
|
||||
|
||||
The `SignInPage` guest provider will now fall back to legacy guest auth if the backend request fails, allowing guest auth without a running backend.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Fixed an issue causing the `repo fix` command to set an incorrect `workspace` property using Windows
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Empty descriptions are not rendered to improve the look&feel.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-backend': patch
|
||||
---
|
||||
|
||||
Fixed bug in stitching queue gauge that included entities that are scheduled in the future.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog': patch
|
||||
---
|
||||
|
||||
Avoiding pre-loading display total count undefined for table counts
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications-backend': patch
|
||||
---
|
||||
|
||||
Add possibility to generate random notifications on the fly in local development
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-scaffolder-backend-module-gitlab': minor
|
||||
---
|
||||
|
||||
Add examples for `gitlab:projectVariable:create` scaffolder action & improve related tests
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Fix to show web notifications even when browser is on foreground. Fix duplicate notifications with multiple tabs.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/cli': patch
|
||||
---
|
||||
|
||||
Add previously-missing semicolon in file templated by `backstage-cli new --select plugin`.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/integration': minor
|
||||
---
|
||||
|
||||
Added `HarnessIntegration` via the `ScmIntegrations` interface.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Allow defining `className` and additional properties for `NotificationsSideBarItem`
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-kubernetes-react': patch
|
||||
---
|
||||
|
||||
add the namespace label to CronJobDrawer & IngressDrawer.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-search': patch
|
||||
---
|
||||
|
||||
Added `aria-label` attribute to DialogTitle element and set `aria-modal` attribute to `true` for improved accessibility in the search modal.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-catalog-node': minor
|
||||
---
|
||||
|
||||
Breaking change to `/alpha` API where the `catalogAnalysisExtensionPoint` has been reworked. The `addLocationAnalyzer` method has been renamed to `addScmLocationAnalyzer`, and a new `setLocationAnalyzer` method has been added which allows the full `LocationAnalyzer` implementation to be overridden.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Fix infinite loop in the notification title counter
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications-backend': patch
|
||||
---
|
||||
|
||||
Updated documentation for sending messages by external services.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
The rendered size of a notification is limited for very long descriptions.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'@backstage/plugin-notifications': patch
|
||||
---
|
||||
|
||||
Add option to set the notification as read automatically when the notification link is opened
|
||||
@@ -1,52 +0,0 @@
|
||||
name: 🔌 Plugin
|
||||
description: 'Submit a proposal for a new Plugin'
|
||||
title: '🔌 Plugin: <title>'
|
||||
labels: [plugin]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
We value your time and efforts to submit this Plugin request form. 🙏
|
||||
- type: textarea
|
||||
id: plugin-summary
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: '🔖 Summary'
|
||||
description: 'Provide a general summary of the plugin and how it should work'
|
||||
placeholder: 'You should add ...'
|
||||
- type: textarea
|
||||
id: website
|
||||
attributes:
|
||||
label: '🌐 Project website (if applicable)'
|
||||
description: 'Add a link to the open source project or product this plugin will integrate with, if existing'
|
||||
placeholder: 'Website Link is ...'
|
||||
- type: textarea
|
||||
id: context
|
||||
attributes:
|
||||
label: '✌️ Context'
|
||||
description: 'A clear and concise description about the Plugin.'
|
||||
placeholder: 'Providing additional context'
|
||||
- type: checkboxes
|
||||
id: no-duplicate-issues
|
||||
attributes:
|
||||
label: '👀 Have you spent some time to check if this plugin request has been raised before?'
|
||||
options:
|
||||
- label: "I checked and didn't find similar issue"
|
||||
required: true
|
||||
- type: checkboxes
|
||||
id: read-code-of-conduct
|
||||
attributes:
|
||||
label: '🏢 Have you read the Code of Conduct?'
|
||||
options:
|
||||
- label: 'I have read the [Code of Conduct](https://github.com/backstage/backstage/blob/master/CODE_OF_CONDUCT.md)'
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: willing-to-submit-pr
|
||||
attributes:
|
||||
label: Are you willing to submit PR?
|
||||
description: This is absolutely not required, but we are happy to guide you in the contribution process.
|
||||
options:
|
||||
- Yes I am willing to submit a PR!
|
||||
- No, but I'm happy to collaborate on a PR with someone else
|
||||
- No, I don't have time to work on this right now
|
||||
@@ -62,6 +62,10 @@
|
||||
matchPackageNames: ['p-limit'],
|
||||
allowedVersions: '<4.0.0',
|
||||
},
|
||||
{
|
||||
matchPackageNames: ['p-throttle'],
|
||||
allowedVersions: '<4.0.0',
|
||||
},
|
||||
{
|
||||
matchPackageNames: ['p-queue'],
|
||||
allowedVersions: '<7.0.0',
|
||||
|
||||
@@ -152,6 +152,8 @@ graphviz
|
||||
Hackathons
|
||||
haproxy
|
||||
hardcoded
|
||||
Harness
|
||||
harness
|
||||
Helidon
|
||||
Henneke
|
||||
Heroku
|
||||
@@ -362,6 +364,8 @@ SIG
|
||||
SIGs
|
||||
siloed
|
||||
Sinon
|
||||
snackbars
|
||||
snackbar
|
||||
Snyk
|
||||
Sonarqube
|
||||
sourcemaps
|
||||
@@ -462,6 +466,7 @@ Weaveworks
|
||||
Webpack
|
||||
widget's
|
||||
winston
|
||||
Wolfi
|
||||
www
|
||||
WWW
|
||||
XCMetrics
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
name: API Breaking Changes (comment)
|
||||
|
||||
on:
|
||||
workflow_run:
|
||||
workflows:
|
||||
- 'API Breaking Changes (Trigger)'
|
||||
types:
|
||||
- completed
|
||||
|
||||
jobs:
|
||||
setup:
|
||||
name: Add values from previous step
|
||||
runs-on: ubuntu-latest
|
||||
if: ${{ github.event.workflow_run.conclusion == 'success' }}
|
||||
permissions:
|
||||
# "If you specify the access for any of these scopes, all of those that are not specified are set to none."
|
||||
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
|
||||
actions: read # Access cache
|
||||
outputs:
|
||||
git-ref: ${{ steps.event.outputs.GIT_REF }}
|
||||
pr-number: ${{ steps.event.outputs.PR_NUMBER }}
|
||||
action: ${{ steps.event.outputs.ACTION }}
|
||||
steps:
|
||||
- name: Harden Runner
|
||||
uses: step-security/harden-runner@63c24ba6bd7ba022e95695ff85de572c04a18142 # v2.7.0
|
||||
with:
|
||||
disable-sudo: true
|
||||
egress-policy: block
|
||||
allowed-endpoints: >
|
||||
api.github.com:443
|
||||
|
||||
- name: 'Download artifacts'
|
||||
# Fetch output (zip archive) from the workflow run that triggered this workflow.
|
||||
uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7.0.1
|
||||
with:
|
||||
script: |
|
||||
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
run_id: context.payload.workflow_run.id,
|
||||
});
|
||||
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
|
||||
return artifact.name == "preview-spec"
|
||||
})[0];
|
||||
if (matchArtifact === undefined) {
|
||||
throw TypeError('Build Artifact not found!');
|
||||
}
|
||||
let download = await github.rest.actions.downloadArtifact({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
artifact_id: matchArtifact.id,
|
||||
archive_format: 'zip',
|
||||
});
|
||||
let fs = require('fs');
|
||||
fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/preview-spec.zip`, Buffer.from(download.data));
|
||||
|
||||
- name: 'Accept event from first stage'
|
||||
run: unzip preview-spec.zip event.json
|
||||
|
||||
- name: Read Event into ENV
|
||||
id: event
|
||||
run: |
|
||||
echo PR_NUMBER=$(jq '.number | tonumber' < event.json) >> $GITHUB_OUTPUT
|
||||
echo ACTION=$(jq --raw-output '.action | tostring | [scan("\\w+")][0]' < event.json) >> $GITHUB_OUTPUT
|
||||
echo GIT_REF=$(jq --raw-output '.pull_request.head.sha | tostring | [scan("\\w+")][0]' < event.json) >> $GITHUB_OUTPUT
|
||||
|
||||
- name: DEBUG - Print Job Outputs
|
||||
if: ${{ runner.debug }}
|
||||
run: |
|
||||
echo "PR number: ${{ steps.event.outputs.PR_NUMBER }}"
|
||||
echo "Git Ref: ${{ steps.event.outputs.GIT_REF }}"
|
||||
echo "Action: ${{ steps.event.outputs.ACTION }}"
|
||||
cat event.json
|
||||
|
||||
- name: Get Comment
|
||||
id: get-comment
|
||||
run: |
|
||||
unzip preview-spec.zip comment.md
|
||||
ls
|
||||
grep
|
||||
|
||||
add-comment:
|
||||
name: Write comment about issues
|
||||
needs:
|
||||
- setup
|
||||
if: ${{ github.event.workflow_run.conclusion == 'success' }}
|
||||
permissions:
|
||||
contents: read
|
||||
pull-requests: write
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4
|
||||
|
||||
# Identify comment to be updated
|
||||
- name: Find comment for API Changes
|
||||
uses: peter-evans/find-comment@3eae4d37986fb5a8592848f6a574fdf654e61f9e # v3
|
||||
id: find-comment
|
||||
with:
|
||||
issue-number: ${{ needs.setup.outputs.pr-number }}
|
||||
comment-author: 'github-actions[bot]'
|
||||
body-includes: API changes
|
||||
direction: last
|
||||
|
||||
- name: Create or Update Comment with API Changes
|
||||
uses: peter-evans/create-or-update-comment@71345be0265236311c031f5c7866368bd1eff043 # v4
|
||||
with:
|
||||
comment-id: ${{ steps.find-comment.outputs.comment-id }}
|
||||
issue-number: ${{ github.event.pull_request.number }}
|
||||
body-path: comment.md
|
||||
edit-mode: replace
|
||||
@@ -0,0 +1,56 @@
|
||||
name: API Breaking Changes (Trigger)
|
||||
on:
|
||||
pull_request:
|
||||
types: [opened, synchronize, reopened, closed]
|
||||
paths:
|
||||
- '**/openapi.yaml'
|
||||
|
||||
jobs:
|
||||
get-backstage-changes:
|
||||
env:
|
||||
NODE_OPTIONS: --max-old-space-size=4096
|
||||
name: Build PR image
|
||||
runs-on: ubuntu-latest
|
||||
if: ${{ github.event_name != 'pull_request' || github.event.action != 'closed' }}
|
||||
steps:
|
||||
- name: Harden Runner
|
||||
uses: step-security/harden-runner@63c24ba6bd7ba022e95695ff85de572c04a18142 # v2.7.0
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
# Fetch the commit that's merged into the base rather than the target ref
|
||||
# This will let us diff only the contents of the PR, without fetching more history
|
||||
ref: 'refs/pull/${{ github.event.pull_request.number }}/merge'
|
||||
- name: fetch base
|
||||
run: git fetch --depth 1 origin ${{ github.base_ref }}
|
||||
|
||||
- name: setup-node
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
with:
|
||||
node-version: 18.x
|
||||
registry-url: https://registry.npmjs.org/
|
||||
|
||||
- name: yarn install
|
||||
uses: backstage/actions/yarn-install@a674369920067381b450d398b27df7039b7ef635 # v0.6.5
|
||||
with:
|
||||
cache-prefix: linux-v18
|
||||
|
||||
- name: breaking changes check
|
||||
run: |
|
||||
yarn backstage-repo-tools repo schema openapi check --since origin/${{ github.base_ref }} > comment.md
|
||||
|
||||
- name: Upload Rendered Comment as Artifact
|
||||
uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32 # v3
|
||||
with:
|
||||
name: preview-spec
|
||||
path: comment.md
|
||||
retention-days: 2
|
||||
|
||||
- name: Upload PR Event as Artifact
|
||||
uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32 # v3.1.3
|
||||
with:
|
||||
name: preview-spec
|
||||
path: ${{ github.event_path }}
|
||||
retention-days: 2
|
||||
@@ -27,7 +27,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
# Fetch the commit that's merged into the base rather than the target ref
|
||||
# This will let us diff only the contents of the PR, without fetching more history
|
||||
|
||||
@@ -28,7 +28,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
ref: '${{ github.event.pull_request.merge_commit_sha }}'
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ jobs:
|
||||
for your contributions.
|
||||
days-before-issue-stale: 60
|
||||
days-before-issue-close: 7
|
||||
exempt-issue-labels: plugin,after-vacations,will-fix
|
||||
exempt-issue-labels: plugin,after-vacations,will-fix,bep
|
||||
stale-issue-label: stale
|
||||
stale-pr-message: >
|
||||
This PR has been automatically marked as stale because it has not had
|
||||
|
||||
@@ -32,7 +32,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
@@ -68,7 +68,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
@@ -197,7 +197,7 @@ jobs:
|
||||
INTEGRATION_TEST_AZURE_TOKEN: ${{ secrets.INTEGRATION_TEST_AZURE_TOKEN }}
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
- name: fetch master branch
|
||||
run: git fetch origin master
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: checkout
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
path: backstage
|
||||
ref: ${{ github.event.client_payload.version && env.RELEASE_VERSION || github.ref }}
|
||||
|
||||
@@ -28,7 +28,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -19,7 +19,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -65,7 +65,7 @@ jobs:
|
||||
INTEGRATION_TEST_AZURE_TOKEN: ${{ secrets.INTEGRATION_TEST_AZURE_TOKEN }}
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
@@ -105,11 +105,11 @@ jobs:
|
||||
- name: test (and upload coverage)
|
||||
run: |
|
||||
yarn backstage-cli repo test --maxWorkers=3 --workerIdleMemoryLimit=1300M --coverage
|
||||
bash <(curl -s https://codecov.io/bash)
|
||||
# bash <(curl -s https://codecov.io/bash)
|
||||
# Upload code coverage for some specific flags. Also see .codecov.yml
|
||||
bash <(curl -s https://codecov.io/bash) -f packages/core-app-api/coverage/* -F core-app-api
|
||||
bash <(curl -s https://codecov.io/bash) -f packages/core-components/coverage/* -F core-components
|
||||
bash <(curl -s https://codecov.io/bash) -f packages/core-plugin-api/coverage/* -F core-plugin-api
|
||||
# bash <(curl -s https://codecov.io/bash) -f packages/core-app-api/coverage/* -F core-app-api
|
||||
# bash <(curl -s https://codecov.io/bash) -f packages/core-components/coverage/* -F core-components
|
||||
# bash <(curl -s https://codecov.io/bash) -f packages/core-plugin-api/coverage/* -F core-plugin-api
|
||||
env:
|
||||
BACKSTAGE_TEST_DISABLE_DOCKER: 1
|
||||
BACKSTAGE_TEST_DATABASE_POSTGRES16_CONNECTION_STRING: postgresql://postgres:postgres@localhost:${{ job.services.postgres16.ports[5432] }}
|
||||
@@ -148,7 +148,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -34,7 +34,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: 'Checkout code'
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
persist-credentials: false
|
||||
|
||||
@@ -66,6 +66,6 @@ jobs:
|
||||
|
||||
# Upload the results to GitHub's code scanning dashboard.
|
||||
- name: 'Upload to code-scanning'
|
||||
uses: github/codeql-action/upload-sarif@c7f9125735019aa87cfc361530512d50ea439c71 # v3.25.1
|
||||
uses: github/codeql-action/upload-sarif@d39d31e687223d841ef683f52467bd88e9b21c14 # v3.25.3
|
||||
with:
|
||||
sarif_file: results.sarif
|
||||
|
||||
@@ -14,7 +14,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
# Fetch changes to previous commit - required for 'only_changed' in Prettier action
|
||||
fetch-depth: 0
|
||||
|
||||
@@ -16,7 +16,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
fetch-depth: 2
|
||||
ref: ${{ github.head_ref }}
|
||||
|
||||
@@ -21,7 +21,7 @@ jobs:
|
||||
run: npm install semver@7.3.5 fs-extra@10.0.0 @manypkg/get-packages@1.1.1
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
path: backstage
|
||||
# 'v' prefix is added here for the tag, we keep it out of the manifest logic
|
||||
@@ -29,7 +29,7 @@ jobs:
|
||||
|
||||
# Checkout backstage/versions into /backstage/versions, which is where store the output
|
||||
- name: Checkout versions
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
repository: backstage/versions
|
||||
path: backstage/versions
|
||||
|
||||
@@ -16,7 +16,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
fetch-depth: 2
|
||||
ref: ${{ github.head_ref }}
|
||||
|
||||
@@ -16,7 +16,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -29,7 +29,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
- name: Monitor and Synchronize Snyk Policies
|
||||
uses: snyk/actions/node@8349f9043a8b7f0f3ee8885bf28f0b388d2446e8 # master
|
||||
with:
|
||||
@@ -58,6 +58,6 @@ jobs:
|
||||
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
|
||||
NODE_OPTIONS: --max-old-space-size=7168
|
||||
- name: Upload Snyk report
|
||||
uses: github/codeql-action/upload-sarif@c7f9125735019aa87cfc361530512d50ea439c71 # v3.25.1
|
||||
uses: github/codeql-action/upload-sarif@d39d31e687223d841ef683f52467bd88e9b21c14 # v3.25.3
|
||||
with:
|
||||
sarif_file: snyk.sarif
|
||||
|
||||
@@ -18,7 +18,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
fetch-depth: 20000
|
||||
fetch-tags: true
|
||||
|
||||
@@ -31,7 +31,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: checkout
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: setup-node
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
@@ -89,7 +89,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: Checkout git repo
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
- name: Render Compose File
|
||||
run: |
|
||||
# update image after the build above
|
||||
|
||||
@@ -24,7 +24,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
- name: Use Node.js 18.x
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
with:
|
||||
|
||||
@@ -47,7 +47,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
# We must fetch at least the immediate parents so that if this is
|
||||
# a pull request then we can checkout the head.
|
||||
@@ -55,7 +55,7 @@ jobs:
|
||||
|
||||
# Initializes the CodeQL tools for scanning.
|
||||
- name: Initialize CodeQL
|
||||
uses: github/codeql-action/init@c7f9125735019aa87cfc361530512d50ea439c71 # v3.25.1
|
||||
uses: github/codeql-action/init@d39d31e687223d841ef683f52467bd88e9b21c14 # v3.25.3
|
||||
with:
|
||||
languages: ${{ matrix.language }}
|
||||
# If you wish to specify custom queries, you can do so here or in a config file.
|
||||
@@ -66,7 +66,7 @@ jobs:
|
||||
# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
|
||||
# If this step fails, then you should remove it and run the build manually (see below)
|
||||
- name: Autobuild
|
||||
uses: github/codeql-action/autobuild@c7f9125735019aa87cfc361530512d50ea439c71 # v3.25.1
|
||||
uses: github/codeql-action/autobuild@d39d31e687223d841ef683f52467bd88e9b21c14 # v3.25.3
|
||||
|
||||
# ℹ️ Command-line programs to run using the OS shell.
|
||||
# 📚 https://git.io/JvXDl
|
||||
@@ -80,4 +80,4 @@ jobs:
|
||||
# make release
|
||||
|
||||
- name: Perform CodeQL Analysis
|
||||
uses: github/codeql-action/analyze@c7f9125735019aa87cfc361530512d50ea439c71 # v3.25.1
|
||||
uses: github/codeql-action/analyze@d39d31e687223d841ef683f52467bd88e9b21c14 # v3.25.3
|
||||
|
||||
@@ -16,7 +16,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
# Vale does not support file excludes, so we use the script to generate a list of files instead
|
||||
# The action also does not allow args or a local config file to be passed in, so the files array
|
||||
|
||||
@@ -26,7 +26,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -45,7 +45,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: Configure Git
|
||||
run: |
|
||||
|
||||
@@ -34,7 +34,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
- uses: actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d # v5.1.0
|
||||
with:
|
||||
python-version: '3.9'
|
||||
|
||||
@@ -42,7 +42,7 @@ jobs:
|
||||
git config --global core.autocrlf false
|
||||
git config --global core.eol lf
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: Configure Git
|
||||
run: |
|
||||
|
||||
@@ -19,7 +19,7 @@ jobs:
|
||||
egress-policy: audit
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: Install Fossa
|
||||
run: "curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install.sh | bash"
|
||||
|
||||
@@ -28,12 +28,18 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js 18.x
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
with:
|
||||
node-version: 18.x
|
||||
- uses: actions/setup-python@v5
|
||||
with:
|
||||
python-version: '3.9'
|
||||
|
||||
- name: Install MkDocs dependencies
|
||||
run: pip install mkdocs mkdocs-techdocs-core
|
||||
|
||||
# Skip caching of microsite dependencies, it keeps the global cache size
|
||||
# smaller, which make Windows builds a lot faster for the rest of the project.
|
||||
@@ -47,9 +53,6 @@ jobs:
|
||||
- name: build API reference
|
||||
run: yarn build:api-docs
|
||||
|
||||
- name: Install MkDocs dependencies
|
||||
run: pip3 install mkdocs mkdocs-techdocs-core
|
||||
|
||||
- name: Build MkDocs for TechDocs
|
||||
run: mkdocs build --strict
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: Use Node.js 18.x
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -32,7 +32,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
with:
|
||||
fetch-depth: 0 # Required to retrieve git history
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ jobs:
|
||||
with:
|
||||
egress-policy: audit
|
||||
|
||||
- uses: actions/checkout@1d96c772d19495a3b5c517cd2bc0cb401ea0529f # v4.1.3
|
||||
- uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b # v4.1.4
|
||||
|
||||
- name: use node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
diff --git a/dist/changesets-assemble-release-plan.cjs.js b/dist/changesets-assemble-release-plan.cjs.js
|
||||
index ee5c0f67fabadeb112e9f238d8b144a4d125830f..9b0e1a156dd88cee35f82faf718d82a8a8f80325 100644
|
||||
--- a/dist/changesets-assemble-release-plan.cjs.js
|
||||
+++ b/dist/changesets-assemble-release-plan.cjs.js
|
||||
@@ -179,12 +179,23 @@ function getDependencyVersionRanges(dependentPkgJSON, dependencyRelease) {
|
||||
if (!versionRange) continue;
|
||||
|
||||
if (versionRange.startsWith("workspace:")) {
|
||||
+ // intentionally keep other workspace ranges untouched
|
||||
+ // this has to be fixed but this should only be done when adding appropriate tests
|
||||
+ let workspaceRange = versionRange.replace(/^workspace:/, "");
|
||||
+ switch (workspaceRange) {
|
||||
+ case "*":
|
||||
+ // workspace:* actually means the current exact version, and not a wildcard similar to a reguler * range
|
||||
+ workspaceRange = dependencyRelease.oldVersion;
|
||||
+ break;
|
||||
+ case "~":
|
||||
+ case "^":
|
||||
+ // Use ^oldVersion for workspace:^ or ~oldVersion for workspace:~.
|
||||
+ // The version range might have changed in dependent package, but that should have its own changeset bumping that package.
|
||||
+ workspaceRange += dependencyRelease.oldVersion;
|
||||
+ }
|
||||
dependencyVersionRanges.push({
|
||||
depType: type,
|
||||
- versionRange: // intentionally keep other workspace ranges untouched
|
||||
- // this has to be fixed but this should only be done when adding appropriate tests
|
||||
- versionRange === "workspace:*" ? // workspace:* actually means the current exact version, and not a wildcard similar to a reguler * range
|
||||
- dependencyRelease.oldVersion : versionRange.replace(/^workspace:/, "")
|
||||
+ versionRange: workspaceRange,
|
||||
});
|
||||
} else {
|
||||
dependencyVersionRanges.push({
|
||||
@@ -262,6 +262,7 @@ _You can do this by using the [Adopter form](https://info.backstage.spotify.com/
|
||||
| [Cielo](https://www.cielo.com.br) | [@Alex Silva](https://github.com/narokwq) | We are using as our Internal Developer Portal, it provides developers with the resources, information, and tools they need to build high-quality applications and adhere to organizational standards and security practices. |
|
||||
| [Giant Swarm](https://giantswarm.io) | [Lucas Weatherhog](https://github.com/weatherhog) | At Giant Swarm we are using Backstage as our internal developer portal. Heavily using the service catalog and the TechDocs plugin. Further looking into adopting functionalities of our Web UI into Backstage to have a single pane of glass for our core business, managing all our components, and helping developers to be more productive. |
|
||||
| [WD Studios](https://wdstudios.tech) | [Mikael Aboagye](https://github.com/JailbreakPapa) | We are using Backstage as our main internal developer portal for our Programmers and Studio Partners. It's really proven its worth at our studio with on-boarding new programmers! |
|
||||
| [Anuclei](https://anuclei.com) | [Mark Jackson](https://github.com/markjacksonfishing) | At Anuclei, we are using Backstage as our internal portal for developers, providing all the tools and guidance needed for full-stack software projects. It simplifies our development methods, making innovation and investment in new ideas consistent and easy to repeat.
|
||||
| [Fortnox](https://www.fortnox.se) | [@magnusp](https://github.com/magnusp) | With Backstage we consolidate our internal tools into a single pane of glass and let the catalog drive our user interface. Our software templates onboard our services and teams onto Backstage, and with Techdocs we are letting our developers get back in control of their own documentation. |
|
||||
| [Wefox](https://www.wefox.com) | [@dibenlloch](https://github.com/dibenlloch) | Internal developer portal to consolidate all developers dashboards, company inventory with compliance reports, team management and self-service portal for IT/Team operations. |
|
||||
| [Aurora Innovation](https://aurorainnovation.com) | [@O5ten](https://github.com/O5ten) | Heavy usage of scaffolder, techdocs, homepage, k8s plugin and homegrown plugins to track migration paths and so on within a developer portal. It acts as a starting point for new and old developers to find all of our internal tooling in one place.
|
||||
|
||||
-233
@@ -1,233 +0,0 @@
|
||||
# Project Areas
|
||||
|
||||
The Backstage project is divided into several project areas, each covering particular parts of the project. The main driver for each area is ownership of code in the main Backstage repository, as well as other repositories in the Backstage GitHub organization. Each area has a set of maintainers and repository content that they own. There may be no overlap in ownership between areas, which means that any given line in the GitHub code owners file should have only one owner specified. Each area is represented by a team in the Backstage GitHub organization. Apart from certain project-wide concerns, such as the release process, each area is self-governing and chooses their own ways of working. Project areas may also have special interest groups (SIGs) related to their area, but this is not required.
|
||||
|
||||
The project areas as well as their maintainers are listed in the [OWNERS.md](./OWNERS.md) file.
|
||||
|
||||
Each project area must have at least one maintainer. Project area maintainers may have shared ownership with the core maintainers, which in that case is considered an incubating area. The project area maintainers help drive work forward in the area, but they might not yet feel ready to take on ownership. The goal should generally be that these project area maintainers eventually become sole maintainers of the project area. This is to allow for a more smooth onboarding and transition of ownership, where members of the community might for example be new to open source maintainership.
|
||||
|
||||
## Adding new project areas
|
||||
|
||||
Project areas are added by nominating new maintainers for that area. See the sections for becoming a [Project Area Maintainer](#project-area-maintainer).
|
||||
|
||||
Project areas may also by added by splitting existing areas. Every area that is created through this process must have at least one maintainer.
|
||||
|
||||
## Removing project areas
|
||||
|
||||
Project areas are removed by removing all maintainers for that area and removing the corresponding team from the Backstage GitHub organization. The project area can be re-added later if there is a need for it. Reasons for removal may include lack of activity, lack of maintainers, or lack of relevance to the project.
|
||||
|
||||
# Project Roles
|
||||
|
||||
## Contributor
|
||||
|
||||
A Contributor contributes directly to the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
|
||||
- Follow the project [contributing guide](CONTRIBUTING.md)
|
||||
|
||||
### How to get involved
|
||||
|
||||
- Participate in community discussions
|
||||
- Help other users
|
||||
- Submit bug reports
|
||||
- Comment on issues
|
||||
- Try out new releases
|
||||
- Attend community events
|
||||
|
||||
### How to contribute
|
||||
|
||||
- Report and sometimes resolve issues
|
||||
- Occasionally submit PRs
|
||||
- Contribute to the documentation
|
||||
- Show up at meetings, take notes
|
||||
- Answer questions from other community members
|
||||
- Submit feedback on issues and PRs
|
||||
- Test releases and patches and submit reviews
|
||||
- Run or help run events
|
||||
- Promote the project in public
|
||||
|
||||
## Organization Member
|
||||
|
||||
An org member is a frequent contributor that has become a member of the Backstage GitHub organization. In addition to the responsibilities of contributors, an org member is also expected to be reasonably active in the community through continuous contributions of any type.
|
||||
|
||||
An Organization Member must meet the responsibilities and has the requirements of a Contributor.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Continues to contribute regularly, as demonstrated by having at least 10 GitHub contributions per year in [Devstats](https://backstage.devstats.cncf.io/d/48/users-statistics-by-repository-group?orgId=1&var-period=y&var-metric=contributions&var-repogroup_name=All&from=now-1y&to=now&var-users=All), or contributions of a similar effort that might not be captured in Devstats.
|
||||
|
||||
### Requirements
|
||||
|
||||
- Must have at least 10 contributions to the projects in the form of:
|
||||
- Accepted PRs
|
||||
- Helpful PR reviews
|
||||
- Resolving GitHub issues
|
||||
- Or some equivalent contributions to the project
|
||||
- Must have been contributing for at least 3 months
|
||||
- Or is the member of a team that owns a project area, in which case the above requirements do not apply and the member is instead vetted by the project area maintainers
|
||||
|
||||
### Becoming an Organization Member
|
||||
|
||||
Open an issue towards [the community repository](https://github.com/backstage/community) using the [org membership request template](https://github.com/backstage/community/issues/new?template=org_member.yaml&title=Org+Member%3A+%3Cyour-github-login%3E).
|
||||
|
||||
### Privileges
|
||||
|
||||
- Membership in the Backstage GitHub organization
|
||||
|
||||
## Plugin Maintainer
|
||||
|
||||
A Plugin Maintainer is responsible for maintaining an individual Backstage plugin or module. This includes reviewing contributions and responding to issues towards an individual plugin, as well as keeping the plugin up to date.
|
||||
|
||||
Plugin Maintainer is a lightweight form of ownership that is primarily reflected though code owners of the plugin packages in the [CODEOWNERS](./.github/CODEOWNERS) file. Each plugin can have one or more maintainers. If a plugin becomes a significant part of the Backstage ecosystem, it may be promoted to be a distinct project area instead.
|
||||
|
||||
A Plugin Maintainer has all the rights and responsibilities of an Organization Member.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Review the majority of PRs towards the plugin
|
||||
- Respond to GitHub issues related to the plugin
|
||||
- Keep the plugin up-to-date with Backstage libraries and other dependencies
|
||||
- Follow the [reviewing guide](REVIEWING.md)
|
||||
|
||||
### Requirements
|
||||
|
||||
- Is an Organization Member
|
||||
- Display knowledge of Backstage's review process and best practices for plugin design
|
||||
- Is supportive of new and occasional contributors and helps get useful PRs in shape to merge
|
||||
|
||||
### Privileges
|
||||
|
||||
- GitHub code owner of the plugin directory, with rights to approve and merge PRs towards the plugin
|
||||
|
||||
### Becoming a Plugin Maintainer
|
||||
|
||||
To become a Plugin Maintainer, you first need to be an Organization Member. You can then file a pull request towards [CODEOWNERS.md](./.github/CODEOWNERS) requesting to be added as a code owner of the plugin directory. Existing code owners of that plugin alongside the core maintainers will then review the request.
|
||||
|
||||
## Project Area Maintainer
|
||||
|
||||
Project Area Maintainers are owners of a particular project area. They are expected to review and merge pull requests towards their area, and also drive development and manage tech health. A Project Area Maintainer also need to commit a certain number of hours per month towards the project, and exercise judgment for the good of the project, independent of their employer. Project Area Maintainers should also mentor new maintainers and participate in and lead community meetings related to their area. New Project Area Maintainers need to be approved by the existing project area maintainers, or the core maintainers if it is a new area.
|
||||
|
||||
The maintainers of a project area may be represented by a team in external organization. In this case, the state as a project area maintainer is tied to the membership in that team. New members of the team may automatically be added as maintainers, as well as removed when they leave. This process is governed autonomously by the team of project area maintainers.
|
||||
|
||||
A Project Area Maintainer has all the rights and responsibilities of an Organization Member.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Review PRs towards their project area. Project area maintainers are expected to review at least 20 PRs per year, or the majority of all PRs towards the area, if it is less than 20
|
||||
- Follow the [reviewing guide](REVIEWING.md)
|
||||
- Triage and respond to issues related to their project area
|
||||
- Mentor new project area maintainers
|
||||
- Write refactoring PRs
|
||||
- Determine strategy and policy for the project area
|
||||
- Participate in or leading community meetings related to their project area
|
||||
|
||||
### Requirements
|
||||
|
||||
- Is an Organization Member
|
||||
- Have made at least 5 meaningful contributions towards the project area
|
||||
- Demonstrates knowledge of their project area, and how it fits into the larger Backstage project
|
||||
- Is able to exercise judgment for the good of the project, independent of their employer, friends, or team
|
||||
- Mentors other contributors and project area maintainers
|
||||
- Can commit to spending at least 16 hours per month working on the project, preferably distributed evenly across the month
|
||||
|
||||
### Privileges
|
||||
|
||||
- Approve and merge PRs towards their project area
|
||||
- Drive the direction and roadmap of their project area
|
||||
|
||||
### Becoming a Project Area Maintainer
|
||||
|
||||
If you are interested in becoming a project area maintainer, reach out to the existing maintainers for that area. If you wish to become a maintainer for a new area, reach out to the core maintainers.
|
||||
|
||||
Any current project area maintainer or core maintainer may nominate a new project area maintainer by opening a PR towards the [OWNERS.md](OWNERS.md) file. A majority of the project area maintainers for that area must approve the PR. If there are no existing maintainers for that area, the PR must be approved by a majority of the core maintainers.
|
||||
|
||||
## Core Maintainer
|
||||
|
||||
Core Maintainers are responsible for the Backstage project as a whole. They help review and merge project-level pull requests as well as coordinate work affecting multiple project areas. A core maintainer needs to commit the majority of their working time towards the project, and exercise judgment for the good of the project, independent of their employer. Core maintainers should also mentor and seek out new maintainers, lead community meetings, and communicate with the CNCF on behalf of the project. To become a core maintainer one needs to have been the maintainer of a number of different project areas, demonstrate a deep knowledge of large parts of the Backstage project, and be backed by the existing core maintainers.
|
||||
|
||||
A Core Maintainer have all the rights and responsibilities of a Project Area Maintainer.
|
||||
|
||||
### Responsibilities
|
||||
|
||||
- Take part in the incoming issue and PR triage and review process. PRs are shared equally among all maintainers
|
||||
- Mentor new Project Area Maintainers and Plugin Maintainers
|
||||
- Drive refactoring and manage tech health across the entire project
|
||||
- Participate in CNCF maintainer activities
|
||||
- Respond to security incidents in accordance to our [security policy](./SECURITY.md)
|
||||
- Determine strategy and policy for the project
|
||||
- Participate in or leading community meetings
|
||||
|
||||
### Requirements
|
||||
|
||||
- Experience as a Project Area Maintainer for at least 6 months
|
||||
- Demonstrates a broad knowledge of the project across multiple areas
|
||||
- Is able to exercise judgment for the good of the project, independent of their employer, friends, or team
|
||||
- Mentors other contributors
|
||||
- Can commit to spending at least 10 days per month working on the project
|
||||
|
||||
### Privileges
|
||||
|
||||
- Approve PRs that fall outside any specific project area
|
||||
- Merge PRs to any area of the project
|
||||
- Represent the project in public as a Maintainer
|
||||
- Communicate with the CNCF on behalf of the project
|
||||
- Have a vote in Maintainer decision-making meetings
|
||||
|
||||
### Becoming a Core Maintainer
|
||||
|
||||
Any core maintainer or end user sponsor may nominate a new core maintainer by opening a PR towards the [OWNERS.md](OWNERS.md) file. Core maintainers must be approved by a majority of the existing core maintainers and end user sponsors.
|
||||
|
||||
## End User Sponsors
|
||||
|
||||
### Role of a Backstage End User Sponsor
|
||||
|
||||
- Provide support for Backstage by removing blockers, securing funding, providing advocacy, feedback, and ensuring project continuity and long term success
|
||||
- Assist Backstage maintainers in prioritizing upcoming roadmap items and planned work
|
||||
- Provide neutral mediation for any disputes that arise as part of the project
|
||||
|
||||
### Backstage End User Sponsor Membership
|
||||
|
||||
The End User Sponsors group comprises at most 5 people. To be eligible for membership in the group, you or the company where you work you must:
|
||||
|
||||
- Be responsible for and end user of a production Backstage deployment of non-trivial size
|
||||
- Be active contributors to the open source project
|
||||
- Be willing and able to attend regularly-scheduled End User Sponsor meetings
|
||||
- Abide by [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
|
||||
|
||||
Candidates for membership will be nominated by current Sponsor members or by Backstage maintainers. If there are more nominations than Sponsor seats remaining, existing sponsors shall vote on the candidates, and the candidates with the most votes will become Sponsors. Any ties will be broken by current Backstage sponsors.
|
||||
|
||||
# Conflict resolution and voting
|
||||
|
||||
In general, we prefer that technical issues and membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the sponsors and core maintainers can be called in to decide an issue. If the sponsors and maintainers themselves cannot decide an issue, the issue will be resolved by voting.
|
||||
|
||||
In all cases in this document where voting is mentioned, the voting process is a simple majority in which each sponsor receives two votes and each core maintainer receives one vote. If such a majority is reached, the vote is said to have _passed_.
|
||||
|
||||
## Inactivity
|
||||
|
||||
It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a loss of trust in the project.
|
||||
|
||||
Inactivity is measured by periods of no contributions without explanation, for longer than:
|
||||
|
||||
- Core Maintainer: 2 months
|
||||
- Project Area Maintainer: 4 months
|
||||
- Plugin Maintainer: 6 months
|
||||
- Organization Member: 12 months
|
||||
|
||||
Consequences of being inactive include:
|
||||
|
||||
- Involuntary removal or demotion
|
||||
- Being asked to move to Emeritus status
|
||||
|
||||
## Involuntary Removal or Demotion
|
||||
|
||||
Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opens up opportunities for new contributors to step in.
|
||||
|
||||
Involuntary removal or demotion is handled through a vote by a majority of the current Core Maintainers. Some aspects of this process may be automated, such as removal after periods of inactivity.
|
||||
|
||||
## Stepping Down/Emeritus Process
|
||||
|
||||
If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project).
|
||||
|
||||
Contact the Maintainers about changing to Emeritus status, or reducing your contributor level.
|
||||
@@ -5,3 +5,4 @@ Portions of this software were developed by third-party software vendors:
|
||||
|
||||
- Tech Radar Plugin (https://opensource.zalando.com/tech-radar/), Copyright (c) 2017 Zalando SE
|
||||
- [OpenAPI Generator Templates](./packages/repo-tools/templates), Copyright 2018 OpenAPI-Generator Contributors (https://openapi-generator.tech) Copyright 2018 SmartBear Software
|
||||
- Optic CLI (https://github.com/opticdev/optic), Copyright 2022, Optic Labs Corporation
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
- See [CONTRIBUTING.md](CONTRIBUTING.md) for general contribution guidelines.
|
||||
- See [GOVERNANCE.md](GOVERNANCE.md) for governance guidelines and responsibilities.
|
||||
- See [GOVERNANCE.md](https://github.com/backstage/community/blob/main/GOVERNANCE.md) for governance guidelines and responsibilities.
|
||||
|
||||
## Core Maintainers
|
||||
|
||||
|
||||
@@ -9,6 +9,9 @@ app:
|
||||
# applicationId: qwerty
|
||||
# site: # datadoghq.eu default = datadoghq.com
|
||||
# env: # optional
|
||||
# sessionSampleRate: 100
|
||||
# sessionReplaySampleRate: 0
|
||||
|
||||
support:
|
||||
url: https://github.com/backstage/backstage/issues # Used by common ErrorPage
|
||||
items: # Used by common SupportButton component
|
||||
|
||||
@@ -12,9 +12,7 @@ creation-date: 2024-03-30
|
||||
|
||||
# BEP: Authentication of External Services
|
||||
|
||||
<!-- Before merging the initial BEP PR, create a feature issue and update the below link. You can wait with this step until the BEP is ready to be merged. -->
|
||||
|
||||
[**Discussion Issue**](https://github.com/backstage/backstage/issues/NNNNN)
|
||||
[**Discussion Issue**](https://github.com/backstage/backstage/issues/24349)
|
||||
|
||||
- [Summary](#summary)
|
||||
- [Motivation](#motivation)
|
||||
@@ -28,17 +26,15 @@ creation-date: 2024-03-30
|
||||
|
||||
## Summary
|
||||
|
||||
This proposal builds upon the foundation laid out in the 0003-auth-architecture-evolution BEP by introducing an authentication mechanism designed for external callers seeking to access the REST APIs exposed by Backstage or its plugins.
|
||||
This proposal builds upon the foundation laid out in the [Auth Architecture Evolution BEP](https://github.com/backstage/backstage/tree/master/beps/0003-auth-architecture-evolution), by improving the authentication mechanisms used by external callers seeking to access the REST APIs exposed by Backstage plugins.
|
||||
|
||||
This addition is not intended to supplant or offer an alternative to existing JWT tokens utilized for backend-to-backend or frontend-to-backend communication. JWT tokens remain a viable option for external callers. However, this proposal presents additional options to simplify usage, especially in heterogeneous setups.
|
||||
Specifically, the inclusion of shared-key based authentication is proposed, along with a framework for integrating different authentication types in the future. Compatibility with the legacy shared-secret token signature mechanism is retained.
|
||||
|
||||
Specifically, the inclusion of shared-key based authentication is proposed, along with a framework for integrating different authentication types in the future.
|
||||
|
||||
By implementing this proposed solution, security should not be compromised beyond the existing state when exposing the API to the internet. Nonetheless, it is advisable to maintain a level of protection by shielding the API from direct internet access.
|
||||
By implementing this proposed solution, security should not be compromised beyond the existing state when exposing the API to the internet. Nonetheless, it is advisable to maintain a level of protection by shielding your deployments from the internet access unless you explicitly need public access.
|
||||
|
||||
## Motivation
|
||||
|
||||
This proposal represents a progression from the tutorial in https://backstage.io/docs/auth/service-to-service-auth/#usage-in-external-callers in the context of the new Authentication service.
|
||||
This proposal represents a progression from [the old service to service auth tutorial](https://backstage.io/docs/auth/service-to-service-auth--old/#usage-in-external-callers) in the context of the new `coreServices.auth` and `coreServices.httpAuth` authentication services.
|
||||
|
||||
It offers expanded configuration possibilities and will include ready-to-use examples as part of the implementation to streamline the process of invoking REST services exposed by Backstage backend plugins for external services.
|
||||
|
||||
@@ -46,12 +42,16 @@ The previous tutorial lacked clarity on how to effectively structure the call, r
|
||||
|
||||
Examples of potential use-cases include:
|
||||
|
||||
- An external asynchronous service requiring the ability to send notifications to users. To facilitate this process, no code change but configuration only is needed on the Backstage side.
|
||||
- An external asynchronous service requiring the ability to send notifications to users
|
||||
- Integrations for external services interacting with the catalog
|
||||
- Temporary `curl` friendly tokens in local development
|
||||
|
||||
To facilitate this process, no code change but configuration only is needed on the Backstage side.
|
||||
|
||||
### Goals
|
||||
|
||||
- The primary objective is to facilitate access for external heterogeneous services to the Backstage REST API without involving unnecessary complexity.
|
||||
- This addition is entirely optional. JWT tokens remain mandatory for all internal communication within Backstage.
|
||||
- Moving to the proposed new auth scheme is entirely optional. The old shared key signature tokens remain usable.
|
||||
- Configuration options will allow specification of which API endpoints can be accessed by an external entity.
|
||||
- Limiting API context and granting distinct external access independently helps mitigate security risks. A compromised external service can only access a restricted portion of the API.
|
||||
- Enhanced clarity and updated examples make it easy to comprehend and utilize.
|
||||
@@ -60,54 +60,108 @@ Examples of potential use-cases include:
|
||||
|
||||
It is not a goal
|
||||
|
||||
- to replace the current Backstage service-to-service authentication or tokens,
|
||||
- to offer a bypass option for Backstage plugins to circumvent existing service-to-service authentication. Even if feasible, such a bypass would be considered as an anti-pattern.
|
||||
- To replace the current Backstage service-to-service authentication or tokens,
|
||||
- To offer a bypass option for Backstage plugins to circumvent existing service-to-service authentication. Even if feasible, such a bypass would be considered as an anti-pattern.
|
||||
|
||||
## Proposal
|
||||
|
||||
The `app-config.yaml` `backend.auth.keys` property will become an array containing alternative authentication mechanisms for callers.
|
||||
The `backend.auth.keys` section of your app config remains supported for the time being, but is considered legacy. It is read by the new auth handler code solely for backward compatibility reasons. Using this format will lead to a logged warning urging a migration to the new format described below.
|
||||
|
||||
JWT tokens remain obligatory for internal Backstage calls and become optional for external callers. Given the complexity associated with composing JWT tokens by external entities, alternative authentication options will be provided for external callers:
|
||||
This BEP adds a `backend.auth.externalAccess` section to your app config. This section is the new recommended way of declaring all methods of external service access that you want to support. Like the legacy section above, it is an array, but each element has a `type` field to allow for extensibility. Using an array also means that the configuration system will not make any config merging of access methods across different config files - which avoids unintended mistakes that might otherwise have impacted security.
|
||||
|
||||
```
|
||||
backend:
|
||||
auth:
|
||||
keys:
|
||||
- type: static
|
||||
value: ${SERVICE_API_KEY}
|
||||
context: '/'
|
||||
- type: jwks
|
||||
value: https://other-service.acme.org/.well-known/jwks.json
|
||||
context: '/foo'
|
||||
- type: certificate
|
||||
value:
|
||||
$file: ./service-cert.pem
|
||||
context: '/foo/bar'
|
||||
```
|
||||
|
||||
The static type is designed for a straightforward shared-key strategy. In this approach, an external service provides a secret string to authenticate itself and access REST resources within a specified context. The shared key is transmitted via a new request header, `authorization_static`.
|
||||
|
||||
Ideally, each external service should have its own unique secret key, even when accessing the same context. If a service requires access to different, separate contexts, multiple corresponding entries will be added to the configuration.
|
||||
|
||||
While other authentication types are provided as examples for potential future expansions, they will not be implemented in the initial phase. However, additional types, including those not yet defined, can be introduced in subsequent phases.
|
||||
|
||||
Introducing a new external caller with its exclusive secret key entails updating the app-config.yaml file and restarting the backend. This mechanism is designed to support integration with selected services, and therefore dynamic addition of callers is not necessary.
|
||||
|
||||
New type-specific functions, such as authenticateStatic(), will be integrated into the AuthService, alongside the existing authenticate() function, which will remain dedicated to JWT tokens.
|
||||
|
||||
No changes will be made to the existing APIs, as any necessary adjustments can be incorporated within private functions of the existing DefaultHttpAuthService implementation.
|
||||
|
||||
Specifically, the DefaultHttpAuthService.extractCredentialsFromRequest function will continue to retrieve a bearer token in JWT format from the authorization header as before. If this header is absent, the service will proceed to read and manage the header corresponding to the next authentication type.
|
||||
|
||||
Furthermore, the options parameter of the HttpAuthService.credentials() function will be expanded to include a new context property. This property will be compared to the value of the context configuration property associated with the corresponding authentication key. If the context parameter is not a subset of the configuration property, the request will be denied.
|
||||
The two types of external access covered by this BEP are `legacy` and `static`. More on that below.
|
||||
|
||||
## Design Details
|
||||
|
||||
<!--
|
||||
This section should contain enough information that the specifics of your
|
||||
change are understandable. This may include API specs or even code snippets.
|
||||
If there's any ambiguity about HOW your proposal will be implemented, this is the place to discuss them.
|
||||
-->
|
||||
### Configuration
|
||||
|
||||
The following is an example of what an app config section with a single access method could look like:
|
||||
|
||||
```yaml
|
||||
backend:
|
||||
auth:
|
||||
externalAccess:
|
||||
- type: static
|
||||
options:
|
||||
token: ${SERVICE_API_TOKEN}
|
||||
scope:
|
||||
plugins: catalog
|
||||
```
|
||||
|
||||
Each entry has a `type`, which is any string. The framework handles a number of these types - initially a fixed set, but in the future we might make it extensible.
|
||||
|
||||
The `options` is a general object, and is specific to each type, configuring it as needed. This particular type only had a `token`, which was configured to be taken from an environment variable.
|
||||
|
||||
Each entry may also optionally have a `scope` section that controls what operations that this entry can be used for. Attempting to use this access method for any other scope will lead to 403 error rejections. Scopes can contain plugin IDs and/or permissions.
|
||||
|
||||
Introducing a new external caller with its exclusive secret key entails updating the app-config.yaml file and restarting the backend. This mechanism is designed to support integration with selected services, and therefore dynamic addition of callers is not necessary at this point.
|
||||
|
||||
### Scopes
|
||||
|
||||
Scopes are optional. If you do not specify any scopes, the access method in question has unlimited scope and can perform all types of action.
|
||||
|
||||
In the examples below, either a string or a list of strings can be given.
|
||||
|
||||
If _any_ scope rule matches, the action is permitted. I.e., if you specify a plugin rule, then also adding permission rules for that plugin will have no effect since the plugin rule will have already matched.
|
||||
|
||||
You can limit by the target plugin ID being accessed with the token:
|
||||
|
||||
```yaml
|
||||
scope:
|
||||
plugin: catalog
|
||||
```
|
||||
|
||||
You can limit by the type of permission being requested:
|
||||
|
||||
```yaml
|
||||
scope:
|
||||
permission: catalog.entity.read
|
||||
```
|
||||
|
||||
Or by permissions attribute:
|
||||
|
||||
```yaml
|
||||
scope:
|
||||
permissionAttributes: { action: read }
|
||||
```
|
||||
|
||||
### The Legacy Access Type
|
||||
|
||||
Configuration example:
|
||||
|
||||
```yaml
|
||||
backend:
|
||||
auth:
|
||||
externalAccess:
|
||||
- type: legacy
|
||||
options:
|
||||
secret: ${EXTERNAL_ACCESS_SIGNATURE_SECRET}
|
||||
# scope: ...
|
||||
```
|
||||
|
||||
This corresponds exactly to the old shared secret signature method, and any secrets entered here will be merged with those specified under `backend.auth.keys` if any.
|
||||
|
||||
### The Static Access Type
|
||||
|
||||
Configuration example:
|
||||
|
||||
```yaml
|
||||
backend:
|
||||
auth:
|
||||
externalAccess:
|
||||
- type: static
|
||||
options:
|
||||
token: ${SERVICE_API_TOKEN}
|
||||
# scope: ...
|
||||
```
|
||||
|
||||
This allows you to specify any static token string as an API key, which callers send verbatim as the header `Authorization: Bearer <token>`.
|
||||
|
||||
### Implementation
|
||||
|
||||
The token verification of the two access methods will live entirely with the `coreServices.auth` service implementation, and will be returning regular credentials with a service principal. The implementation will only need to alter the `authenticate` method and no additions to the API will be necessary.
|
||||
|
||||
The service principal type will need to be amended with an optional scope field, carried over from the configuration. This will let the `ServerPermissionClient` compare against the set of allowlisted actions. In addition, the auth service can early-reject based on plugin ID if such rules are given.
|
||||
|
||||
## Release Plan
|
||||
|
||||
@@ -117,13 +171,30 @@ This section should describe the rollout process for any new features. It must t
|
||||
If there is any particular feedback to be gathered during the rollout, this should be described here as well.
|
||||
-->
|
||||
|
||||
TBD
|
||||
The initial pilot implementation of the `legacy` and `static` types has already been merged, along with the corresponding config additions.
|
||||
|
||||
- adding different types in the future
|
||||
Validating this implementation, and adding scope restrictions, is still on todo but could be added incrementally at any time without breaking changes - as long as the default scope is "all".
|
||||
|
||||
We have left it out of the scope of this BEP to allow for addition of more access types. Making that a possibility will likely require the addition of service extension points at a framework level, which is not yet made a priority.
|
||||
|
||||
Potential _future_ access types (not part of this BEP, but rather only for illustration) could for example be:
|
||||
|
||||
```yaml
|
||||
backend:
|
||||
auth:
|
||||
externalAccess:
|
||||
- type: jwks
|
||||
options:
|
||||
url: https://other-service.acme.org/.well-known/jwks.json
|
||||
- type: certificate
|
||||
options:
|
||||
publicCert:
|
||||
$file: ./service-cert.pem
|
||||
```
|
||||
|
||||
## Dependencies
|
||||
|
||||
- 0003-auth-architecture-evolution
|
||||
- [BEP-0003: Auth Architecture Evolution](https://github.com/backstage/backstage/tree/master/beps/0003-auth-architecture-evolution)
|
||||
|
||||
## Alternatives
|
||||
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
# Minimal Hardened Image for Backstage
|
||||
|
||||
DockerHub images in general did not seem ideal for Backstage as the number of vulnerabilities were quite high regardless of the image used.
|
||||
|
||||
The `Dockerfile` in this directory uses a [`wolfi-base`](https://github.com/wolfi-dev) image from Chainguard Images. This improves the security of the application and reduces false positives in scanners.
|
||||
|
||||
## Considerations
|
||||
|
||||
- `Wolfi` only releases the `latest` tag for public consumption however digests can be pinned.
|
||||
- `Wolfi` OS uses packages from the [os repository](https://github.com/wolfi-dev/os) on GitHub. Some packages may be named differently.
|
||||
- While `Wolfi` uses `apk`, the OS is designed to support `glibc`.
|
||||
- Due to the stripped down nature of the base image, additional packages might be needed compared to a distribution like Debian or Ubuntu.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user