You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Alex Herbert <al...@gmail.com> on 2025/09/17 12:41:26 UTC
[CMS] Website buildbot is broken
I have updated the component properties and doap for the Statistics 1.2 release:
https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/doap_statistics.rdf
https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
I believe the build bot may have failed as the site was not available here:
https://commons.apache.org/proper/
I had some manual steps to try using the CMS trunk checkout if the
build bot fails. The first one is to parse the releases and this
failed:
> conf/parse-latest-release.py
bcel 6.10.0 2024-07-24
Traceback (most recent call last):
...
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/distutils/version.py",
line 137, in parse
raise ValueError("invalid version number '%s'" % vstring)
ValueError: invalid version number '2.0.0-m1'
The issue is files with pre-release modifiers with lower-case m, e.g:
doap/doap_beanutils.rdf: <revision>2.0.0-m1</revision>
doap/doap_collections.rdf: <revision>4.5.0-m2</revision>
I corrected parse-latest-release.py to handle lower case modifiers as
it previously expected uppercase M. The script now runs but it heavily
changes the component_release.properties file. Some of the doap files
are out-of-date and the versions are downgraded, e.g. text, dbutils,
csv. And some entries are removed as they must have been manually
added: beanutils1, beanutils2 -> beanutils; fileupload2 -> removed.
If I ignore parse-latest-release.py and use the existing
component_releases.properties then I can build the site locally using
commons-site-build.sh. I could then proceed to publish the site to the
staging area which looks OK but has missing icons before version
numbers. I then published this using commons-site-publish.sh which
restored the site. This still has missing icons before version numbers
but I believe this is due to ASF policy not allowing external resource
URLs from the pages hosted at the apache.org domain.
TLDR:
- Editing a doap after a release does not rebuild the site as the
build bot does not create the correct component_releases.properties.
- Some doap files are out-of-date with their latest releases.
- I had to manually update the main site after a component release.
Q. What is the correct process for updating the main site after a
component release? I thought editing the doap file (or
component_releases.properties) was enough and the build bot did the
rest.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CMS] Website buildbot is broken
Posted by sebb <se...@gmail.com>.
On Wed, 17 Sept 2025 at 13:41, Alex Herbert <al...@gmail.com> wrote:
>
> I have updated the component properties and doap for the Statistics 1.2 release:
>
> https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/doap_statistics.rdf
> https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
>
> I believe the build bot may have failed as the site was not available here:
>
> https://commons.apache.org/proper/
>
> I had some manual steps to try using the CMS trunk checkout if the
> build bot fails. The first one is to parse the releases and this
> failed:
>
> > conf/parse-latest-release.py
> bcel 6.10.0 2024-07-24
> Traceback (most recent call last):
> ...
> File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/distutils/version.py",
> line 137, in parse
> raise ValueError("invalid version number '%s'" % vstring)
> ValueError: invalid version number '2.0.0-m1'
>
> The issue is files with pre-release modifiers with lower-case m, e.g:
>
> doap/doap_beanutils.rdf: <revision>2.0.0-m1</revision>
> doap/doap_collections.rdf: <revision>4.5.0-m2</revision>
>
> I corrected parse-latest-release.py to handle lower case modifiers as
> it previously expected uppercase M. The script now runs but it heavily
> changes the component_release.properties file. Some of the doap files
> are out-of-date and the versions are downgraded, e.g. text, dbutils,
> csv. And some entries are removed as they must have been manually
> added: beanutils1, beanutils2 -> beanutils; fileupload2 -> removed.
>
> If I ignore parse-latest-release.py and use the existing
> component_releases.properties then I can build the site locally using
> commons-site-build.sh. I could then proceed to publish the site to the
> staging area which looks OK but has missing icons before version
> numbers. I then published this using commons-site-publish.sh which
> restored the site. This still has missing icons before version numbers
> but I believe this is due to ASF policy not allowing external resource
> URLs from the pages hosted at the apache.org domain.
>
> TLDR:
> - Editing a doap after a release does not rebuild the site as the
> build bot does not create the correct component_releases.properties.
> - Some doap files are out-of-date with their latest releases.
> - I had to manually update the main site after a component release.
>
> Q. What is the correct process for updating the main site after a
> component release? I thought editing the doap file (or
> component_releases.properties) was enough and the build bot did the
> rest.
Normally, that is the case.
However it looks like the buildbot environment was recently updated,
and Java 1.8 is no longer available.
See for example:
https://ci2.apache.org/#/builders/91/builds/235
I've updated the BB script to use Java 17; hopefully it will be a
while before that is dropped.
The build process is fully described in
https://svn.apache.org/repos/asf/commons/cms-site/trunk/BUILDING.txt
There are scripts for building locally.
Note that commons-site-build.sh does not automatically commit to the
staging site.
You need to do that yourself (assuming the diffs look OK).
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org