Generate SVG and go-licenses.json at build time

[silverwind]

• When no SVG files are present, backend renders text placeholders. We could add a dummy icon as well instead if preferred.
• When no go licenses are present, they are omitted from licenses.txt with a warning.

This enables to update npm and go dependencies without having to run post-upgrade steps, a quasi-prerequisite to using dependency update bots.

The Makefile still keeps a strict frontend/backend separation with no dependencies between them, but I think that separation should eventually go as it causes unnecessary complexity as seen in the actions changes.

Code changes are in 7cf7974, the other commit is the removals.

[wxiaoguang]

No, not right

[wxiaoguang]

By the way, I don't think it is maintainable to keep copying these uses: steps.

No way to share the duplicate steps?

[silverwind]

No, not right

Expected as documented in OP. Do you want me to add a placeholder instead?

By the way, I don't think it is maintainable to keep copying these uses: steps.

Yes we can extract to a reusable workflow and run it via workflow_call or some other step-reuse (need to check docs).

[TheFox0x7]

yaml anchors work too :)

That aside, does this not cripple the license audit a bit? Right now we can check the on a PR to see if the license is detected properly for new dependencies if they show up and to check if the PR doesn't add something that would be problematic.

Didn't the attempt to move to renovate gain traction from being able to run post commands after update as opposed to dependabot?

[silverwind]

Yes, license diff will now go unnoticed, that is the drawback. I don't think anyone really looks at this much during review.

Post-update step could be implemented in renovate but would still need to be explained to every contributor, causing friction.

[TheFox0x7]

I don't think anyone really looks at this much during review.

I am, that's why I'm asking.

[silverwind]

Maybe it's better to codify some rules for acceptable licenses like we already do for JS dependencies than rely on manual review. Not sure how good the license classification is for go deps given that those carry no SPDX identifiers, but worth a try if a suitable go module for classification exists.

[wxiaoguang]

No, not right

Expected as documented in OP. Do you want me to add a placeholder instead?

Now, make watch-frontend + run Gitea server, you just don't see any SVG icon.

How can it be right? What placeholder can be right?

[silverwind]

Now, make watch-frontend + run Gitea server, you just don't see any SVG icon.

watch-frontend has the dependency, so the SVG build runs, but it does run concurrently with the backend startup creating a race condition and backend never reloads files with the current mechanism. I think backend needs the ability to reload SVG files.

[TheFox0x7]

I'm not looking at the license, I'm looking at the entire bundle - what was added, why was it added, does it match what I can dig out manually.
It's not "does this accidentally pull GPL?" which you can catch with trivy or something alike, its a "does the new addition/removal match what the project requires at to keep at minimum". It's a rare thing that it changes but I'd rather be able to look at it if I can, just to be sure the license text isn't garbage or just a reference.
I find it useful in that regard.

[silverwind]

Yes, I agree it's useful side-info.

[silverwind]

Decided to keep the generated files for now, so the renovate PR needs to adopt a post-update script.