Hi everyone, To run the website tests, we must install the missing dependencies on the remote runner. Can anyone help with this?
https://github.com/apache/zookeeper/actions/runs/24838423432/job/72730186177?pr=2373#step:5:7082 Regards, Yurii On Fri, Apr 17, 2026 at 4:27 PM Yurii Palamarchuk < [email protected]> wrote: > Sure. I'm opening a PR now! > > On Thu, Apr 16, 2026 at 3:31 PM Andor Molnár <[email protected]> wrote: > >> Thanks David. >> >> Totally agree. >> Can we move on with the new website Yurii? >> What do you need to open pull request? What are the open questions? >> >> Andor >> >> >> >> >> > On Apr 16, 2026, at 02:07, Dávid Paksy <[email protected]> wrote: >> > >> > Hi All, >> > >> > In the meantime the Apache Phoenix team merged the new website, you can >> see >> > it here: https://phoenix.apache.org/. >> > >> > On the other day I had to wait for an hour and I only had my smartphone >> on >> > me and I was able to read ZooKeeper documentation from the redesigned >> > website and learn from it. While not impossible, it would be harder to >> do >> > this with the current documentation pages. >> > >> > Regarding security vulnerabilities, actually the current ZooKeeper >> website >> > page contains Bootstrap v4.1.3 which is end-of-life and contains one >> known >> > XSS vulnerability and jQuery v3.3.1 which contains 4 known security >> > vulnerabilities, including the critical CVE-2019-11358 (Prototype >> > Pollution) and multiple Cross-Site Scripting (XSS) issues. >> > >> > Personally I'd vote for technical modernization here to fix the current >> > CVE-s and because this also makes the documentation more easy to >> approach. >> > I can also offer my help in the website dependency updates. >> > >> > Best Regards, >> > Dávid >> > >> > >> > Yurii Palamarchuk <[email protected]> ezt írta (időpont: >> 2026. >> > ápr. 2., Cs, 10:48): >> > >> >> Here is the code: >> >> >> >> https://github.com/yuriipalam/zookeeper-website >> >> >> >> It's not a PR for the zookeeper repo yet. >> >> >> >> Regards, >> >> Yurii >> >> >> >> On Thu, Apr 2, 2026 at 3:33 AM Christopher <[email protected]> >> wrote: >> >> >> >>> Where is the code for the react version of the site? >> >>> >> >>> On Wed, Apr 1, 2026 at 2:53 AM Dávid Paksy <[email protected]> >> wrote: >> >>>> >> >>>> Hi All, >> >>>> >> >>>> To have a sense about maintenance need, you can see the JavaScript >> >>>> dependabot PR-s in the HBase repo here: >> >>>> >> >>>> >> >>> >> >> >> https://github.com/apache/hbase/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+label%3Ajavascript >> >>>> >> >>>> So yes, it requires some maintenance. >> >>>> I'd also recommend to enable Dependabot dependency updates as they >> are >> >>>> helpful. But if not, running 'npm audit fix' manually is rather easy. >> >>>> >> >>>> For how the sources look you can check here what Yuri implemented for >> >>> HBase: >> >>>> >> >>>> https://github.com/apache/hbase/tree/master/hbase-website >> >>>> >> >>>> >> >>>> Best regards, >> >>>> Dávid >> >>>> >> >>>> Christopher <[email protected]> ezt írta (időpont: 2026. márc. >> 31., >> >> Ke >> >>>> 22:47): >> >>>> >> >>>>> It's also pretty easy to use dependabot on the website repo to check >> >>>>> for updated site dependencies. That should be easy to handle if the >> >>>>> assets are included in the repo itself, and not loaded from other >> >>>>> domains, as per the ASF policy >> >>>>> (https://privacy.apache.org/policies/website-policy.html) >> >>>>> >> >>>>> On Tue, Mar 31, 2026 at 11:05 AM Yurii Palamarchuk >> >>>>> <[email protected]> wrote: >> >>>>>> >> >>>>>> I know about it, and we're not affected by it. This vulnerability >> >>> allows >> >>>>>> attackers to bypass the React's server authentication, but we don't >> >>> use >> >>>>> it. >> >>>>>> We don't have any runtime node.js server, so we aren't affected by >> >>> any of >> >>>>>> these. >> >>>>>> >> >>>>>> Best Regards, >> >>>>>> Yurii >> >>>>>> >> >>>>>> On Tue, Mar 31, 2026 at 4:38 PM Patrick Hunt <[email protected]> >> >>> wrote: >> >>>>>> >> >>>>>>> this is from december :-) >> >>>>>>> >> >>> >> https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 >> >>>>>>> >> >>>>>>> Patrick >> >>>>>>> >> >>>>>>> On Tue, Mar 31, 2026 at 7:27 AM Yurii Palamarchuk < >> >>>>>>> [email protected]> wrote: >> >>>>>>> >> >>>>>>>> You are right, there are almost no concerns. The entire website >> >>> is >> >>>>>>> static, >> >>>>>>>> only the server providing the assets is running. The only issue >> >>>>> could be >> >>>>>>> if >> >>>>>>>> some node.js package becomes vulnerable, allowing hackers to >> >> run >> >>>>> scripts >> >>>>>>> on >> >>>>>>>> users' machines, but this scenario is highly unlikely. >> >>>>>>>> >> >>>>>>>> Best Regards, >> >>>>>>>> Yurii >> >>>>>>>> >> >>>>>>>> On Tue, Mar 31, 2026 at 4:22 PM Patrick Hunt <[email protected] >> >>> >> >>>>> wrote: >> >>>>>>>> >> >>>>>>>>> What are the security implications of running React on the ZK >> >>>>> website? >> >>>>>>> Is >> >>>>>>>>> that going to mean additional concerns (eg cve tracking as >> >>> well as >> >>>>>>> source >> >>>>>>>>> security bugs, tracking the "latest react" version and so >> >>> on...). I >> >>>>>>>>> believe right now we just have very simple static pages which >> >>>>> require >> >>>>>>>> very >> >>>>>>>>> minimal oversight? >> >>>>>>>>> >> >>>>>>>>> Regards, >> >>>>>>>>> >> >>>>>>>>> Patrick >> >>>>>>>>> >> >>>>>>>>> On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk < >> >>>>>>>>> [email protected]> wrote: >> >>>>>>>>> >> >>>>>>>>>> Thanks everyone for your reviews! >> >>>>>>>>>> >> >>>>>>>>>> The only approach I considered for updating the >> >> documentation >> >>>>> version >> >>>>>>>> is >> >>>>>>>>> a >> >>>>>>>>>> manual one. It looks like this: >> >>>>>>>>>> 1) Checkout to the `website` branch. >> >>>>>>>>>> 2) Build the latest change for the current version, right >> >>> before >> >>>>> the >> >>>>>>>>>> update. >> >>>>>>>>>> 3) Move the build to `public/released-docs/` and rename the >> >>>>> directory >> >>>>>>>> to >> >>>>>>>>>> the corresponding version. >> >>>>>>>>>> 4) Update the `CURRENT_VERSION` constant, so now it matches >> >>> the >> >>>>> new >> >>>>>>>>>> version. >> >>>>>>>>>> 5) Open a PR. >> >>>>>>>>>> >> >>>>>>>>>> The Java API docs are built by maven as far as I can tell, >> >> so >> >>>>> it's >> >>>>>>> not >> >>>>>>>>>> related to the website actually. >> >>>>>>>>>> >> >>>>>>>>>> Regarding the automatization of this process, I've never >> >> done >> >>>>>>> anything >> >>>>>>>>> like >> >>>>>>>>>> this before. Therefore, if you have any suggestions - I'm >> >>> open to >> >>>>>>> it, I >> >>>>>>>>>> think it should be possible since the workflow is not >> >>> complex at >> >>>>> all. >> >>>>>>>>> Most >> >>>>>>>>>> likely a small bash script could be enough. >> >>>>>>>>>> >> >>>>>>>>>> Best Regards, >> >>>>>>>>>> Yurii >> >>>>>>>>>> >> >>>>>>>>>> On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár < >> >>> [email protected]> >> >>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Exactly. My 2 cents are: >> >>>>>>>>>>> >> >>>>>>>>>>> 1. Storing the entire website at a single location is >> >>>>> desirable. >> >>>>>>>> Given >> >>>>>>>>>> the >> >>>>>>>>>>> proposed >> >>>>>>>>>>> technology changes there’s no clear separation possible >> >>> without >> >>>>>>>>>> duplicating >> >>>>>>>>>>> website core logic components which will be a maintenance >> >>>>> nightmare >> >>>>>>>> in >> >>>>>>>>>> the >> >>>>>>>>>>> long term. >> >>>>>>>>>>> >> >>>>>>>>>>> 2. Separate ‘website’ branch or versioned branches. As >> >>> Patrick >> >>>>>>>>> mentioned >> >>>>>>>>>>> the docs are versioned and the ability to accompany doc >> >>> changes >> >>>>>>> with >> >>>>>>>>>>> code changes in the same PR is a big advantage. >> >>>>>>>>>>> >> >>>>>>>>>>> Andor >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> On Mar 30, 2026, at 19:52, Patrick Hunt < >> >>> [email protected]> >> >>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> One reason I remember the docs/api/etc... are part of >> >> the >> >>>>> source >> >>>>>>> is >> >>>>>>>>>> that >> >>>>>>>>>>>> they are versioned along with it. PRs -- doc changes >> >>> along >> >>>>> with >> >>>>>>>> code >> >>>>>>>>>>>> changes also part of the release process. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Patrick >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Mon, Mar 30, 2026 at 5:39 PM Christopher < >> >>>>> [email protected] >> >>>>>>>> >> >>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> I think it looks great, but I would really like to see >> >>> the >> >>>>> SCM >> >>>>>>>>> source >> >>>>>>>>>>>>> for this new site, so I can understand the >> >>> maintenance/build >> >>>>>>>>> workflow >> >>>>>>>>>>>>> for it, before I'd have any useful opinion other than >> >>>>> regarding >> >>>>>>>>>>>>> aesthetics. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I definitely concur with moving the docs out to the >> >>> site to >> >>>>>>>>> centralize >> >>>>>>>>>>> it. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk >> >>>>>>>>>>>>> <[email protected]> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Thanks for your comment, Patrick. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Why React? >> >>>>>>>>>>>>>> Building a website nowadays is not just HTML + CSS, >> >>> because >> >>>>>>> doing >> >>>>>>>>> it >> >>>>>>>>>>> this >> >>>>>>>>>>>>>> way turns the developer experience into a nightmare. >> >>> With >> >>>>> React >> >>>>>>>> we >> >>>>>>>>>>>>>> effortlessly have consistent UI components across all >> >>>>> pages, >> >>>>>>>>>> including >> >>>>>>>>>>>>>> buttons, tables, markdown rendering, colors, and much >> >>>>> more. We >> >>>>>>>> also >> >>>>>>>>>> add >> >>>>>>>>>>>>> the >> >>>>>>>>>>>>>> interactivity much more easily with React. A static >> >>> website >> >>>>>>>> doesn't >> >>>>>>>>>>> mean >> >>>>>>>>>>>>> it >> >>>>>>>>>>>>>> lacks interactivity; it often has significant >> >>>>> interactivity, >> >>>>>>>>>> especially >> >>>>>>>>>>>>> in >> >>>>>>>>>>>>>> the documentation section. The difference is that we >> >>> don't >> >>>>> need >> >>>>>>>> any >> >>>>>>>>>>>>> runtime >> >>>>>>>>>>>>>> environment, we just return the files generated at >> >>> build >> >>>>> time, >> >>>>>>>>> which >> >>>>>>>>>>> are >> >>>>>>>>>>>>>> ultimately just HTML, CSS, and JS. The website also >> >> has >> >>>>> dark >> >>>>>>> mode >> >>>>>>>>>>>>> support, >> >>>>>>>>>>>>>> search in the documentation, smooth transitions >> >> between >> >>>>> pages >> >>>>>>> (no >> >>>>>>>>>> hard >> >>>>>>>>>>>>>> reload), so it gives smooth and better user >> >> experience >> >>>>>>> overall. I >> >>>>>>>>>> hope >> >>>>>>>>>>>>> this >> >>>>>>>>>>>>>> answers your question. Moreover, the website will >> >> work >> >>>>>>> absolutely >> >>>>>>>>>> fine >> >>>>>>>>>>>>> even >> >>>>>>>>>>>>>> for those who have JS disabled, this is called >> >>> progressive >> >>>>>>>>>> enhancement. >> >>>>>>>>>>>>>> Initially, the server returns HTML and CSS. The >> >> browser >> >>>>> renders >> >>>>>>>>> them >> >>>>>>>>>>> and >> >>>>>>>>>>>>>> tries to fetch the JS files. If it doesn't succeed, >> >> the >> >>>>> page >> >>>>>>>>> remains >> >>>>>>>>>>>>>> accessible, though it obviously lacks interactivity. >> >> I >> >>> hope >> >>>>>>> this >> >>>>>>>>>>> answers >> >>>>>>>>>>>>>> your questions, if not, feel free to ask more about >> >> it! >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Is it hard for ZK devs to update the content? >> >>>>>>>>>>>>>> Not at all! I tried to make it so the learning curve >> >>> for >> >>>>> non-JS >> >>>>>>>>> devs >> >>>>>>>>>> is >> >>>>>>>>>>>>>> almost 0. For the documentation you still just need >> >> to >> >>>>> edit the >> >>>>>>>> MDX >> >>>>>>>>>>>>>> (Markdown Extended) files and run the build command. >> >> I >> >>> will >> >>>>>>> also >> >>>>>>>>> add >> >>>>>>>>>> a >> >>>>>>>>>>>>> bash >> >>>>>>>>>>>>>> script to automate the build process. For the landing >> >>>>> pages, >> >>>>>>> you >> >>>>>>>>>> still >> >>>>>>>>>>>>>> mostly only need to modify the markdown files. Only >> >> the >> >>>>> main >> >>>>>>> page >> >>>>>>>>>> isn't >> >>>>>>>>>>>>>> markdown, modifying something small wouldn't be a >> >>> problem. >> >>>>> In >> >>>>>>> the >> >>>>>>>>>> worst >> >>>>>>>>>>>>>> case, if something more complex is required, you can >> >>>>> handle it >> >>>>>>>> with >> >>>>>>>>>> the >> >>>>>>>>>>>>> AI. >> >>>>>>>>>>>>>> Nevertheless, the website hasn't been updated for >> >>> years, >> >>>>> so it >> >>>>>>>>>> wouldn't >> >>>>>>>>>>>>> be >> >>>>>>>>>>>>>> a big loss :) >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>>> Yurii >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt < >> >>>>> [email protected] >> >>>>>>>> >> >>>>>>>>>> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk < >> >>>>>>>>>>>>>>> [email protected]> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Hi there, >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> I am proposing an upgrade to the ZooKeeper website >> >>> and >> >>>>>>>>>>>>> documentation. We >> >>>>>>>>>>>>>>>> are moving to a modern React.js stack, which allows >> >>>>> landing >> >>>>>>>> pages >> >>>>>>>>>> and >> >>>>>>>>>>>>>>>> versioned documentation to live in a single >> >>> application >> >>>>>>> sharing >> >>>>>>>>> the >> >>>>>>>>>>>>> same >> >>>>>>>>>>>>>>> UI >> >>>>>>>>>>>>>>>> components, libraries, colors, etc. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> The plan is to move all website and documentation >> >>> source >> >>>>> code >> >>>>>>>> to >> >>>>>>>>>> the >> >>>>>>>>>>>>>>>> website branch and remove the zookeeper-docs Maven >> >>>>> project >> >>>>>>> from >> >>>>>>>>> the >> >>>>>>>>>>>>>>> master >> >>>>>>>>>>>>>>>> branch. This decouples the Node/JS build >> >> environment >> >>>>> from the >> >>>>>>>>> core >> >>>>>>>>>>>>> Java >> >>>>>>>>>>>>>>>> repository. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Versioned docs will be managed via archived folders >> >>>>> within >> >>>>>>> the >> >>>>>>>>>>>>> website >> >>>>>>>>>>>>>>>> branch. Documentation updates would move from >> >> master >> >>> to >> >>>>> PRs >> >>>>>>>>> against >> >>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>> website branch. Also I'm not planning to keep the >> >>> app as >> >>>>> a >> >>>>>>>> maven >> >>>>>>>>>>>>> project, >> >>>>>>>>>>>>>>>> since it's fully JS based. To keep it simple, I >> >> will >> >>>>> write a >> >>>>>>>> bash >> >>>>>>>>>>>>> script >> >>>>>>>>>>>>>>>> that installs the dependencies, runs the tests, and >> >>> the >> >>>>>>> build. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> What do you think about moving the docs out of >> >>> master to >> >>>>>>>>> centralize >> >>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>> site? >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Preview: https://zookeeper-website.vercel.app/ >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Looks pretty slick - nice update and visual refresh! >> >>>>> Question >> >>>>>>>>>> though - >> >>>>>>>>>>>>> why >> >>>>>>>>>>>>>>> React? This is a static website, what are the >> >> pro/con >> >>> of >> >>>>> React >> >>>>>>>>>> based? >> >>>>>>>>>>>>> Can >> >>>>>>>>>>>>>>> you explain the impact on common use cases like >> >> making >> >>>>>>> updates? >> >>>>>>>> ZK >> >>>>>>>>>>> team >> >>>>>>>>>>>>>>> includes a number of people, not all of whom might >> >>> know >> >>>>> React, >> >>>>>>>> how >> >>>>>>>>>>> hard >> >>>>>>>>>>>>>>> will it be for them to make changes? Impact on the >> >>> release >> >>>>>>>>> process? >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Regards, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Patrick >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>>>>> Yurii Palamarchuk >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> >> >> >>
