Fix ui-release to run on workflow_dispatch and auto-detect boostlook branch

[julioest]

Problem

When boostlook/develop merges a PR and triggers website-v2-docs via workflow_dispatch, the
ui-bundle does not rebuild with the updated CSS because:

1. Line 30: The build job only runs on push events, skipping workflow_dispatch entirely
2. Line 49: BOOSTLOOK_BRANCH defaults to master even when triggered on the develop branch
3. Lines 18-21: The input has required: true with default: 'master', preventing auto-detection

Solution

• Allow workflow_dispatch events in the job condition
• Auto-detect develop branch when no input is provided
• Make the input optional with an empty default to enable auto-detection

Testing

Tested on my fork by:

1. Running workflow_dispatch on develop branch with empty input
2. Verified BOOSTLOOK_BRANCH=develop was used
3. Confirmed ui-bundle.zip contained latest boostlook.css from develop

https://github.com/julioest/website-v2-docs/releases/download/ui-develop/ui-bundle.zip

Refers to issue: boostorg/boostlook#142

[cppalliance-bot]

An automated preview of the documentation is available at https://582.site-docs.prtest2.cppalliance.org/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2026-01-21 20:23:32 UTC

[sdarwin]

There's a certain Github Actions workflow between boostlook <-> website-v2-docs <-> website-v2

Decisions were made, perhaps 1 year ago, when you configured the boostlook and website-v2-doc triggers and git branches and so forth.

Typically you would expect something like master-branch -> updates master-branch, and develop-branch -> updates develop-branch.

However it was not necessarily done that way.

There should be documentation that explains what the workflow is.

Possible locations for the docs are
https://github.com/cppalliance/website-v2-operations in a "boostlook" folder, or a "workflows" folder, or in the boostlook repository itself.

[sdarwin]

@julioest , consider how the workflow is going.

Once a week on a slow deliberate schedule we promote website-v2 from develop to master.

Everything from develop goes into production.

Working "backwards" from that point, we may ask "which version of boostlook should that be, which is now being deployed to production?"

If boostlook-develop is sent to website-v2 develop, then it would develop of boostlook that is important.

In such a scenario, boostlook master would be completely ignored as if it didn't exist.

Which is not impossible... But it's a decision.

Another method would be to prioritize boostlook-master. Copy boostlook-master to website-v2-develop. And that will eventually find it's way to production. If that's what's occurring now, it may be very reasonable, and should not change.

Just because one developer requests something... if they are not informed about the web deployments, it's not necessarily correct.

Could you document the status quo and how it works on the three repos? website-v2, website-v2-docs, and boostlook?

And again, to reiterate, what happens is that approximately once per week, we purposely and carefully merge develop into master, with whatever the contents of develop are. When that happens, which version of boostlook should it be? Very possibly the master branch. If this is documented, we can refer others to the explanation, and it is a reference for us also.

[sdarwin]

Maybe it's already the case the develop is the main branch of boostlook.

This PR will trigger ui-bundle builds more frequently, every time boostlook changes. If that is the goal, ok.

[julioest]

Could you document the status quo and how it works on the three repos? website-v2, website-v2-docs, and boostlook?

You're right, there's no documentation for this. Sure thing, I'll add this to our operations