The staging website is broken, with JS integrity errors

[sbp]

https://tooling.staged.apache.org/

None of the “sha384” hashes in the integrity attribute match the content of the subresource at “https://tooling.staged.apache.org/js/bootstrap.bundle.min.js”. The computed hash is “TYMA+uAx4f43rilxPIhmlqA+Vi+xbyMe+YVR3BcL15NyHLqd+7WYNtyBPdayiOPx”. 2 tooling.staged.apache.org

Therefore the menus don't work, which makes navigation impossible.

[jbampton]

#27

This issue is probably from my PR. My mistake in changing the "end of files"

[sbp]

Hmm, but #27 was merged into main and the live Tooling site is fine!

https://tooling.apache.org/

Looking at our branches we don't even have a preview/* branch except for the one that I just made, so I'm not sure why we have a staging site at all or where it came from or how it was built. Mysteries!

[dave2wave]

I think one of the commits yesterday changed these files.

[sbp]

But, even more mysteriously, I branched from main so the files are exactly the same:

$ curl -s https://tooling-sbp-test.staged.apache.org/js/bootstrap.bundle.min.js | shasum -a 384
4d8300fae031e1fe37ae29713c886696a03e562fb16f231ef98551dc170bd793721cba9dfbb59836dc813dd6b288e3f1  -

$ curl -s https://tooling.staged.apache.org/js/bootstrap.bundle.min.js | shasum -a 384
4d8300fae031e1fe37ae29713c886696a03e562fb16f231ef98551dc170bd793721cba9dfbb59836dc813dd6b288e3f1  -

$ curl -s https://tooling.apache.org/js/bootstrap.bundle.min.js | shasum -a 384
4d8300fae031e1fe37ae29713c886696a03e562fb16f231ef98551dc170bd793721cba9dfbb59836dc813dd6b288e3f1  -

I just pushed a change to the integrity value on my branch and now my version of the staging website works.

Meanwhile https://tooling.apache.org/ still has the old integrity value, but it works.

[sbp]

Also, meanwhile, the old staging version got updated:

https://tooling.staged.apache.org/

It now shows just the bare repository content/ file tree. When I loaded it earlier, it was like my version of the staging site, showing a complete site. The commits@ list ought to receive a notification of a build to the tooling website; it did for my test branch. But it has not received a notification of a build to the main staging site, so it's not clear why it's changed.

[sbp]

Note that tooling-sbp-test is built by Buildbot on ASF CI. It mails us the build outputs but it does not mail us the build log, and I'm not sure where to access those logs. On the other hand tooling is built from main using GHA. Using a different CI for staging compared to production means that we could have staging divergences, but we want staging precisely to test the build outcome, so using two different CI systems is not optimal.

[sbp]

I broke the hash deliberately, and now the browser tells me:

None of the “sha384” hashes in the integrity attribute match the content of the subresource at “https://tooling.apache.org/js/bootstrap.bundle.min.js”. The computed hash is “OERcA2EqjJCMA+/3y+gxIOqMEjwtxJY7qPCqsdltbNJuaOe923+mo//f6V8Qbsw3”. tooling.apache.org

This means that the browser is reporting a different hash for https://tooling.apache.org/js/bootstrap.bundle.min.js compared to https://tooling-sbp-test.staged.apache.org/js/bootstrap.bundle.min.js but, again:

$ curl -s https://tooling.apache.org/js/bootstrap.bundle.min.js | shasum -a 384
4d8300fae031e1fe37ae29713c886696a03e562fb16f231ef98551dc170bd793721cba9dfbb59836dc813dd6b288e3f1  -

$ curl -s https://tooling-sbp-test.staged.apache.org/js/bootstrap.bundle.min.js | shasum -a 384
4d8300fae031e1fe37ae29713c886696a03e562fb16f231ef98551dc170bd793721cba9dfbb59836dc813dd6b288e3f1  -

So at this point I of course suspect caching, navigate to https://tooling.apache.org/js/bootstrap.bundle.min.js and reload it manually, and indeed the message changes:

None of the “sha384” hashes in the integrity attribute match the content of the subresource at “https://tooling.apache.org/js/bootstrap.bundle.min.js”. The computed hash is “TYMA+uAx4f43rilxPIhmlqA+Vi+xbyMe+YVR3BcL15NyHLqd+7WYNtyBPdayiOPx”. tooling.apache.org

This is the same hash as given on tooling-sbp-test. What I expect happened is that the changes in #27 did indeed cause a mismatch with the integrity value, but my browser had cached the .js and didn't reload it. Meanwhile because my staged version was a new site, it did a fresh load, and the error showed up there. Another win for staging.

[sbp]

Resolved by f3a0ed9.