[
https://issues.apache.org/jira/browse/CASSANDRA-16913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454546#comment-17454546
]
Anthony Grasso commented on CASSANDRA-16913:
h1. Summary
>From the discussion with [~mck] on
>[#cassandra-website|https://the-asf.slack.com/archives/C01RY1LUPD5] we will
>commit the UI bundle to the repository and reference the local path in the
>Docker file. Details of the Slack discussion are as follows.
h1. Details
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630633750027100]
*Anthony:*
{quote}We need to make a release of the UI bundle and publish it to the GitHub
repository. I can tell you how to build the bundle, but was is the process
after that to do the release? Do we need to raise a vote on the mailing list to
do the release? How do you want to publish the artifacts? The Gulp file inside
the Docker container which generates the bundle has a release task that we
could leverage. It’s designed to create a GitHub release.
{quote}
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630634173029600]
*Anthony:*
{quote}In relation to point 2. above, I noticed that UI bundle URL inside the
content Dockerfile is incorrect. We will need to make a release of the UI
bundle and then update the URL to point to it.
In addition, we should also publish instructions (most likely in the README) on
how to do a UI bundle release. If we use the release task in the Gulp file the
process will be super easy. I’m happy to do the write up for the release
instructions.
{quote}
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630666967035300]
*mck:*
{quote}I have no objection to having to generate the UI bundle each website
build. At least while Lorina's work is not yet merged.
Otherwise I have no objection to checking in the UI bundle into trunk. That way
no releases are required.
That means just defaulting the URL to ./site-ui/build/ui-bundle.zip .
Simplifies things: no releases, maybe no need for CASSANDRA-16913, no need for
a -z flag.
{quote}
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630670470040600]
*Anthony:*
{quote}I think 2. requires some discussion. The bundle is always generated
separately from the website. We would need to rework the ./run.sh script to
have them build serially. I can see cases where you’d want to have the current
version of the bundle used in the live version of the size instead of having a
version rebuilt locally. I still think there is a need for the -z flag
particularly for UI dev workflows.
Having the UI bundle as a released item seems to be the “Antora way” of laying
out resources. I think we should discuss this further at the next website
meeting we have.
{quote}
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630697743041100]
*mck:*
{quote}> The bundle is always generated separately from the website.
yes.
> We would need to rework the ./run.sh script to have them build serially.
I was thinking to keep them separate, as it is today.
> I can see cases where you’d want to have the current version of the bundle
> used in the live version of the size instead of having a version rebuilt
> locally.
yes, that's what happens by default if you don't run ./run.sh website-ui bundle
(the unmodified bundle at site-ui/build/ui-bundle.zip is used)
> I still think there is a need for the -z flag particularly for UI dev
> workflows.
then you do first run ./run.sh website-ui bundle
in which case you then have a modified site-ui/build/ui-bundle.zip
and when ready to "release" it (in your phrasing of it) you git commit
site-ui/build/ui-bundle.zip
at least, that's what i was trying to explain :slightly_smiling_face: happy to
take a chat over it next meeting, no doubt there's antora stuff i'm not aware
of.
{quote}
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630886288052900]
*Anthony:*
{quote}> then you do first run ./run.sh website-ui bundle
> in which case you then have a modified site-ui/build/ui-bundle.zip
> and when ready to “release” it (in your phrasing of it) you git commit
> site-ui/build/ui-bundle.zip
I understand what you’re saying. I think that is a possible solution. Is the
idea to try and simply the release process?
I was thinking it would be good to have site-ui/build/ui-bundle.zip as a
developer working path. Meaning you could override it with a new version of the
UI bundle file anytime. If needed I could always reference the version in
production that is released in GitHub by just running ./run.sh website-ui
bundle . This would save having to change branches or stash changes.
{quote}
[https://the-asf.slack.com/archives/C01RY1LUPD5/p1630920334054200]
*mck:*
{quote}the release terminology is troublesome, as it overlaps with the notion
of an ASF release. That's not possible here because of the licenses involved,
and we wouldn't want it because of the overhead.
but generally, the website r