Nick Boldt

Closing per decision in https://redhat-internal.slack.com/archives/C04CUSD4JSG/p1724938275761529?thread_ts=1724263219.535159&cid=C04CUSD4JSG

Looks good but we might want to address some of those sonarcloud issues. https://sonarcloud.io/project/issues?issueStatuses=OPEN%2CCONFIRMED&pullRequest=1486&types=VULNERABILITY&severities=BLOCKER%2CCRITICAL%2CMAJOR%2CMINOR&inNewCodePeriod=true&sinceLeakPeriod=true&id=janus-idp_backstage-showcase @kim-tsao WDYT?

> short-lived branches when a release is needed So your suggestion is that we 'd have a branch called `workspacename/x.y.z` for each maintenance build? eg., `argocd/1.24.7` to release the 1.24.7...

From a real-life simple example we had recently: * our plugin for RBAC support was updated to include changes in Backstage 1.27 (main branch) * then a CVE was discovered...

Another aspect of this is that it's not always possible to have a plugin support the latest runtime, due to incompatible dependency requirements. We have this problem already brewing with...

To be clear on the code that's causing the problem... is it this? https://github.com/backstage/community-plugins/blob/main/.github/workflows/pr.yml#L26 -> https://github.com/backstage/actions/tree/main/pr-sync Or this? https://github.com/backstage/community-plugins/blob/main/scripts/ci/list-workspaces-with-changes.js ?

@mdb can you resolve conflicts?

Do you need a package-lock.json AND a yarn.lock? https://github.com/backstage/community-plugins/pull/849/files#diff-4162692e00010c60d9372d740a6fae4e576e73c20d3a6ed1eaf7e9eceb788292 https://stackoverflow.com/questions/44552348/should-i-commit-yarn-lock-and-package-lock-json-files

sorted the CODEOWNERS file alphabetically and fixed the merge conflict.

skipping over the failed test because it's a bug in the GH action which Beth has since fixed