Uffizzi Ephemeral Environment deployment-32775

☁️ https://app.uffizzi.com/github.com/backstage/backstage/pull/19249

📄 View Application Logs etc.

What is Uffizzi? Learn more!

@freben : Unsure why the sole CI check failed. Can't make sense out of the logs -

https://github.com/backstage/backstage/actions/runs/5784684796/job/15675859390?pr=19249

do I have to make any changes?

Love that you're helping contribute this one, @NishkarshRaj ! Thanks for helping keep the project safe. ❤️

Looks like there's a conflict in one of the YAMLs, but an overall comment. I wonder if the blast radius 💥 of this PR is perhaps a bit large. The AppSecurity PR review feature is awesome - I've used it before. But via this PR, You're attempting to modify,

• Literally every single GitHub Action in the entire project
• Both pinning action dependencies - which is great - but also setting default permissions (which if done wrong could affect how they work)
• And changing Dockerfile examples in a create app which gets delivered to users when they scaffold and are testing backstage for the first time. (hence your need for the changeset)

So it's sort of like a few different MAJOR things to review, and agree on, to be able to merge in. And a mistake to the workflows could be really impacting.

I know this may add more work, but if I could suggest, I'd break down the changes into smaller PRs. For example, rather than taking literally EVERY SINGLE action change in a single PR, maybe only firing changes to groups of them - ones that perhaps are the easiest like the NOOPS or the ones which are obvious like labeling PRs, or all of the E2E ones together, etc. That way they are a) smaller to review and read, and b) easier to test their impact upon merging.

The repo already has reports on these OpenSSF vulnerabilities now as the project uses the OpenSSF report action, so as we chip away at them the security alerts will get closed out and the maintainers can track them and which are still open. And if we need we can use that AppSecurity review tool iteratively to continue to improve it.

What do you think?

PS: For the maintainers, I happened to recently test just to make sure, but Dependabot is smart in terms of patching that if we specify Git hash in this to help make sure there's no version drift, Dependabot is smart in that it still help us maintain by version and semver, but will maintain the git hash which is a key aspect to help protect build security and supply chain traceability.

Example: https://github.com/adamdmharvey/actions-safe-and-maintained/pull/3/files

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

Hey, sorry I let this linger a bit. I added a needs-discussion tag on this to bring it up at the maintainer sync :)

(needs a rebase now, unfortunately, as well)

@adamdmharvey @freben - Thanks for the response!

I do believe the blast radius of the PR is wide but the notion was always to help improve security.

Given Backstage gets loads of update regularly, I'll keep this open until a maintainer picks it up and re-creates a PR with the App Security utility else a rebase now would become obsolete later.

Happy to discuss and contribute this in small(er) incremental checks.

Security FTW <3

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

@Rugvip : Thanks for the reply.

Basis your requested review changes, I have committed the following:

1. Added Harden Runner for all Actions file (No clue how the tool missed it for some files)
2. Removed pinned SHA dependency on all accepted sources: github/* , backstage/* , actions/* - do we need to extend these to established sources like Docker and Snyk as well?
3. Removed pinned SHA dependency on the base image of Dockerfile.

I removed the extraneous changeset and rebased with master last night - don't know why the build is failing as my changes have not affected any code base per se.

I'll do another rebase with the latest master now but think something @Rugvip @freben you can help me understand better?

@Rugvip @freben Unsure what is breaking the jobs.

There are some markdown references seemingly broken but given I took a merge from the master branch they should have been resolved?

Now something strange with the Discord noti. Any nudges @freben @adamdmharvey @Rugvip ?

I reran the microsite action this morning (US Eastern), in case it was intermittent. Seems it ran clean so that's good ! (It's really slow; almost 2 hours !) Discord notification is usually used only for failed runs ? I'll take a look in a bit to see if we can rerun that or clear it.

@adamdmharvey @Rugvip - any nudges to clean this up and get it shipped?

Thanks for the nudge; re-ran the build job. Let's see!

@Rugvip @adamdmharvey - any chance this failing workflow is related to #19984?

Welp! Some stunts to somehow fix the broken pipeline hell caused me to lose the history - reopened another PR to address these changes here: #20090

cc/ @Rugvip @adamdmharvey @freben