[BUG]: Updating from 3.1.28 to 3.2.5 beta3 doesn't add the necessary repos to the table #1202
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: joomla/Component-Builder#1202
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What Happened?
When i updated from 3.1.28 to 3.2.5 beta3 it didn't populate the repositories table with the necessary repo's needed for joomla powers init function to work.
This will then throw an API error
Super Power repository at https://git.vdm.dev/api/v1/joomla/super-powers gave the following error!
Invalid response received from API.
Super Power repository at https://git.vdm.dev/api/v1/joomla/gitea gave the following error!
Invalid response received from API.
Super Power repository at https://git.vdm.dev/api/v1/joomla/openai gave the following error!
Invalid response received from API.
Would be nice if on update this would be populated so they work out of the box.
Steps to reproduce the Bug
Update fro m3.1.28 to 3.2.5 beta3 and try to update the joomla powers or powers area using the Init button.
Which Joomla version are you compiling in?
3.10.12
Which PHP version are you compiling in?
8.1
Which Joomla versions are you targeting?
3
Which PHP version are you targeting?
8.1
Which Web server is JCB running on?
apache
Which Relational Database is JCB running on?
mariadb 10.4
Which OS is JCB running on?
centos 7
Which JCB version are you using?
3.2.5 beta3
Where in JCB did this issue occur?
Powers(admin_views)
On which browsers did you encounter the issue?
Safari
Additional Comments
No response
[BUG]: Updating rrom 3.1.28 to 3.2.5 beta3 doesn't add the necessary repos to the tableto [BUG]: Updating from 3.1.28 to 3.2.5 beta3 doesn't add the necessary repos to the tableTom, the issue you’re experiencing stems from a situation we’ve encountered where our primary Git system has been overwhelmed by too many requests. As a result, we had to implement a robot verification system, which is unfortunately affecting the API as well.
To address this, we have decentralized all the core endpoints of JCB. Now, you can pull these endpoints from a diverse set of repositories. With the latest release (which is ready but not yet released, as I plan to finalize it next week), we are rolling out a feature that will automatically search for an available repository via an API we’ve established.
In the meantime, there is a workaround for this issue. You can check the status page for JCB, which is accessible via the status button on the git.vdm.dev website (located at the bottom of the page). Once there, scroll down to the JCB status section. You will find a list of alternative server and system endpoints where you can access the repositories. These endpoints are synchronized, so it doesn’t matter which one you use—they all work interchangeably.
To implement the workaround in JCB, go to the repository area and manually change the URL of the endpoint to one of the alternative options provided. This should resolve the problem and allow JCB to function as expected.
The larger context here is that our main repository is hosted on a dedicated LightSail server, which costs about $80/month. While it is a robust setup, JCB’s rapid growth has placed significant strain on this system, pushing it to its limits. Expanding this setup further is an option, but decentralization presents a more sustainable, long-term solution. It ensures that we don’t bear the full load on a single server, which is especially important as we continue to offer JCB as a free tool. By decentralizing, we distribute the load across the community, making the system more resilient.
I’ve personally moved multiple systems to this new decentralized network, and many of my colleagues and clients have done the same. So far, the transition has been smooth, and the decentralized endpoints are functioning well. If you’re encountering specific issues or are unsure how to resolve them, I hope this explanation provides the clarity you need. Similar concerns have been raised on GITI, and I’ve responded to them in a similar manner, offering the same solution.
In summary, while the growth of JCB has introduced some challenges, the steps we’ve taken to decentralize the repository network are designed to ensure stability and scalability in the long term. If further clarification is needed, we can certainly discuss this during the next JUG meeting.
This issue should be resolved in the new JCB 5.1.0 release.
We are working on decentralizing all external connections used by JCB—such as banners and more—with the critical power calls being addressed first and now automated.
Below is the code that accomplishes this:
API Call at Build Start:
At the beginning of the build process, this API call handles everything:
$this->resolve->api($this->target ?? $path->repository, $path->base, $path->organisation, $path->repository);Selecting an Online System:
The function call that attempts to select an online system is:
$this->resolve($target, $domain, $organisation, $repository);Core Engine Implementation:
The engine itself is implemented in the function:
function resolve($target, $domain, $organisation, $repository){…}Availability Monitoring API:
The API for monitoring system availability is accessible at:
https://api.joomlacomponentbuilder.com/v1/network/community/jcb
There is much more to discuss regarding the architecture of this system, but the essence is that all the core repositories we maintain are part of this redundancy network. Since JCB is shipped with
codebergat this point in the call, we first check if it is online; if not, we immediately swap it for another system right here.There is one caveat: if a system goes down after this check, the build process will take a long time and eventually fail. However, an immediate retry should resolve the issue, as a different system will be selected on the new run.
Hi @Llewellyn, we are trying to do this PATH (from J3 to J5):
#1203 (comment)
Starting on a backup of our J3,
We have updated JCB (to 3.2.5) on this J3 instance.
Trying to compile our component, we are facing the issue mentionned in that ticket.
Thus I was wonderring how to achieve this:
Thanks for your help!
Hi,
the error message we have is:
That's probably due to
@fred-the-coder to implement a workaround, you can either install a blank JCB instance and then go to the repositories to copy-paste the values across, or you can check the database of your current JCB release and manually copy the data from there. In either case, you'll need to enter the data manually into your repositories area in JCB database that's what it means to do it manually. Should this codeberg system be down, the other systems are listed here: https://status.vdm.dev/status/jcb all that change is basically the domain name.
@Llewellyn It worked like a charm!
What we have done:
#__componentbuilder_repositoryAnd our component seems to work as before...
Many thx!
We continue the road to J5!!!