[BUG]: Changelog xml is empty #1307
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: joomla/Component-Builder#1307
Reference in new issue
Block a user
What Happened?
In the dynamic update pane I enabled "Add Changelog Server *" and entered a valid path to the public file on my git repository. I set the Changelog Server Target to "Zip" or "Other". Both settings result in the compiled component containing a changelog xml file with only
<changelogs></changelogs>as the content.Steps to reproduce the Bug
Create a public xml file (mine is https://raw.githubusercontent.com/ConfidantCommunications/3DBug-Changelog/refs/heads/main/changelog.xml) and configure the component as described above before compiling.
Which Joomla version are you compiling in?
6.0.3
Which PHP version are you compiling in?
8.3.27
Which Joomla versions are you targeting?
6.0.0
Which PHP version are you targeting?
8.3.27
Which Web server is JCB running on?
Joomla Docker image "joomla:5.4.0-php8.3". Apache 2
Which Relational Database is JCB running on?
mysqlnd 8.3.27
Which OS is JCB running on?
Alpine linux inside Docker on a Mac ARM64
Which JCB version are you using?
6.1.5
Where in JCB did this issue occur?
Compilation of a component
On which browsers did you encounter the issue?
Firefox
Additional Comments
No response
@ConfidantCommunications We are using the exact same setup for JCB itself:
For each release, a component update is created within the system. During this process, there is an option labeled "Server Advanced Options." This setting must be enabled (set to "Yes") for every component update.
Once enabled, an additional section becomes available at the bottom of the interface - specifically, the Changelog field. This is where all relevant changelog entries for the release are added.
Provided that the server update configuration is correctly set - including the update paths, versioning, and associated URLs - the system will automatically process and update the changelog as expected.
So I'm not sure whether this is what you are already doing, but that is our current setup in JCB and it is working.
I hope this helps.
My intended workflow was to first update the xml file on github (I do this manually), then have JCB retrieve the file during the compiling process and include it as "config.xml". However since your message I have discerned that the changelog.xml contains only what gets entered into the JCB "component updates" interface.
In your workflow I unfortunately do not understand how that results in updating the Github file, since that seems designed to use FTP servers in the JCB "servers" area. Can you point me in the right direction?
Also, is there documentation on how to format the changelog text? I had entered XML directly and it got converted to HTML entities in part, and also divided into the different
<security> <fix> <language> <change>etc. tags somehow.@ConfidantCommunications
We use OctoJpack together with OctoZipo to fully automate our Joomla Component Builder (JCB) deployment pipeline.
To better explain the overall process, here is the workflow we follow:
Deployment Pipeline Overview
Within the Dynamic Integration area of JCB, we configure a Backup Folder Path for the component.
When preparing a release, we enable:
YesDuring compilation, JCB generates all install ZIP packages and automatically moves them into the configured backup folder.
From there:
OctoZipo
OctoZipomonitors the backup folder and automatically:This works whether the project consists of:
The behavior is controlled through the OctoZipo configuration.
OctoJpack
OctoJpackthen:This gives us a fully automated release and packaging workflow.
Update Server & Changelog Configuration
The Joomla update server and changelog functionality are configured directly inside JCB.
In the Dynamic Integration section of the component, we configure:
The update server path points to the repository location where the generated ZIP packages are hosted and downloadable.
Component Updates Configuration
Inside the Component Updates area of JCB, each release/version entry includes:
The Version URL is especially important, as it points directly to the ZIP package for that specific release.
This information is then used by JCB to automatically generate:
changelog.xmlChangelog Formatting
JCB automatically categorizes changelog entries based on keywords used in the changelog text.
The parser recognizes the following categories:
fix,fixed,fixesadd,added,addsupdate,updatedremove,removedFor example:
Fixed routing issue in Joomla 5Added support for update server cachingUpdated API response handlingRemoved deprecated helper classAnything not matching the predefined keywords is automatically categorized as a general note.
Generated Files
During compilation, JCB generates:
changelog.xmlCHANGELOG.mdThe generated
changelog.xmlcan typically be found inside the component's public/update area, depending on your configuration.When the component is installed into Joomla:
Under the installed extension version, Joomla provides a clickable changelog view displaying the formatted release history.
Important Configuration Notes
To ensure everything works correctly, the following paths must all be configured properly inside the component's Dynamic Integration area:
These paths are used by JCB during compilation to place:
into their correct repository locations.
The automation provided by OctoZipo and OctoJpack is what makes the entire workflow seamless once configured correctly.
It is admittedly a fairly advanced setup initially, but once everything is configured properly, the entire release, packaging, update server, and changelog workflow becomes highly streamlined and reliable.
I've attached a few example screenshots as reference, and I hope this helps clarify the overall process.
Thanks for all that. I am bookmarking this page! I always admire automated systems like this.
My component is very heavy on front end Javascript development which make it more convenient to be making my change notes in that git repository as I improve the app. The other thing is I am using JReleaser which has its own system of organising releases. I appreciate the help—it's good to have clarity on what the "complete" setup looks like.