Is there a reason that this is only for 4.0-dev can this later also be done for the 3.x branches?

Is there a reason that this is only for 4.0-dev can this later also be done for the 3.x branches?

Yes should be possible for j3 too, I only started with j4 in the first place because it seams people still have problems to use composer and npm.

sure would be great to get it working for 3.x too than ? Awesome feature to be sure!

sure would be great to get it working for 3.x too

The reason that this is needed for the J4 branch more than the 3.x is down to the composer and npm steps that many non devs cannot execute. J3 doesn't have those limitations but still having an installable per PR is a helping hand. Also once this is in for both branches the patch tester can be archived

Also once this is in for both branches the patch tester can be archived

Actually Patchtester has a new maintainer @roland-d so we hopefully see progress on it. Beside this the patchtester solves a different problem, it's much easier to test multiple PRs and revert them. that's not possible if you install a complete package.

So what is the actual benefit to this added build step on every pull request then, since as you’re pointing out it’s not really addressing anything for an end user? Joomla doesn’t support rollback, and barely supports updates if you’re not on a stable tag, so these packages seem to just add more steps to a tester’s workflow because once it is installed into a site then the site has to be destroyed to revert the changes. About the only benefit is for testing the updater, which being realistic, less than 5% of all pull requests require testing that functionality.

This to me is just another facade to say “it’s easy to test Joomla changes” by hiding all of the technical knowledge necessary to actually work with patches or git or Composer or NPM. The project is better off not using these tools over continuing to invest resources it doesn’t have into hiding the fact these tools are necessities for code contributions to this and a growing number of other repositories.

Also once this is in for both branches the patch tester can be archived

This isnt a replacement for patchtester in any way

So what is the actual benefit to this added build step on every pull request then, since as you’re pointing out it’s not really addressing anything for an end user? Joomla doesn’t support rollback, and barely supports updates if you’re not on a stable tag, so these packages seem to just add more steps to a tester’s workflow because once it is installed into a site then the site has to be destroyed to revert the changes. About the only benefit is for testing the updater, which being realistic, less than 5% of all pull requests require testing that functionality.

Actually we have many tester and part time testers and reports who are not able to use composer and npm because they have simple a website and don't do any development. So we simply open the possibility to test to a bigger group of people, especially them we lost when starting to use composer and npm.

This to me is just another facade to say “it’s easy to test Joomla changes” by hiding all of the technical knowledge necessary to actually work with patches or git or Composer or NPM. The project is better off not using these tools over continuing to invest resources it doesn’t have into hiding the fact these tools are necessities for code contributions to this and a growing number of other repositories.

Of course because a tester doesn't need to know anything about the technical infrastructure to test an issue. And the repository is actually only a new branch in our existing docker-images repo, yes one more that's true but we also try to get rid of other unmaintained infrastructure.

I doubt that your target user is going to do a full download and full install

I doubt that your target user is going to do a full download and full install

yes and of course doing updates to test them

HLeithner wrote: > Actually we have many tester and part time testers and reports who are not able to use composer and npm because they have simple a website and don't do any development. So we simply open the possibility to test to a bigger group of people, especially them we lost when starting to use composer and npm.

... as me & other Users :-)

So before this is deployed then I would highly suggest that a workflow is devised for supporting rollback/revert. Because for the level of tester you are targeting here, you are going to get someone who just installs Joomla fresh using the package on the pull request, or if you’re lucky someone who updates a test site using the package on the pull request, but you have left them stranded and unable to further test using that site.

There is a reason I keep saying that people who are testing pull requests should be able to work with git at a minimum. It’s not because I think only the technically privileged should do pull request review and testing (although sometimes I wish that were the case with the number of times I have code reviewed a pull request that was supposedly tested successfully but could have never worked because they introduced different kinds of fatal errors). It’s because from a software workflow perspective, the right tools for the job are the tools necessary to create the pull request in the first place (git, Composer, NPM). Joomla is just not designed as a piece of software that you can do in place testing and revert the changes when you’re done testing. Patch tester, no matter how friendly you make the UI or how much you overengineer it under the hood, will always suffer the same flaw, not because the component is poorly written but because the software it is written for is not intended for that use case.

So before this is deployed then I would highly suggest that a workflow is devised for supporting rollback/revert. Because for the level of tester you are targeting here, you are going to get someone who just installs Joomla fresh using the package on the pull request, or if you’re lucky someone who updates a test site using the package on the pull request, but you have left them stranded and unable to further test using that site.

You know this is not possible with our current database model

There is a reason I keep saying that people who are testing pull requests should be able to work with git at a minimum. It’s not because I think only the technically privileged should do pull request review and testing (although sometimes I wish that were the case with the number of times I have code reviewed a pull request that was supposedly tested successfully but could have never worked because they introduced different kinds of fatal errors). It’s because from a software workflow perspective, the right tools for the job are the tools necessary to create the pull request in the first place (git, Composer, NPM). Joomla is just not designed as a piece of software that you can do in place testing and revert the changes when you’re done testing. Patch tester, no matter how friendly you make the UI or how much you overengineer it under the hood, will always suffer the same flaw, not because the component is poorly written but because the software it is written for is not intended for that use case.

So you say every software tester out there is able to compile the software they are testing? Actually most of the tester doesn't even be able to get the source of the software they are testing. Beside that nightly builds have the exact same problem but they are ok?

If you think it's needed to create a information at the download site that this files are only for tests and should never be installed on a live site and can't be upgraded and 10 other warnings I'm fine with it. But to say "hey you tested joomla the last 15 years and now you are to dumb to use our (partly hard to use and install) dev chain" sounds not as a good solution to me. And we get complaints about this on a regular base.

And yes our user base are not drupal users, till the marketing team finds it out what our main target group is, I assume that our users are "normal" people creating websites (basically I think most of our users are integrators building websites for others and have a hard time creating overrides) and want to help to make joomla better.

Beside that I completely understand your approach require a minimum knowledge our workflow but for testing an ui element in the backend you don't need to know git.

You’re coming to this with the assumption that everyone who clicks the download button on .org should be able to test a pull request from GitHub on a Joomla site. I don’t think that should be the case.

Yes, for some people, it is going to be easier to either install Joomla fresh from a package on a pull request or update a testing site using a package on a pull request then trash the entire installation when they’re done. But to me, that is an inefficient use of people’s time.

WordPress doesn’t have all this extra crap. Can’t use a patch file? Too bad. And they are the king of assuming their users are so stupid that PHP and MySQL are considered profane words instead of trusted software.

So, disregard my feedback. The project generally does anyway.

My stance hasn’t changed over the years. If the tools are too complex for your target user, then the tools need to be changed to match the target user expectations. You’re saying testers are too scared or not savvy enough to use Composer and NPM? To me the solution is to not use those tools, not waste your time, and an entire team’s time, coming up with software solutions that are half assed and don’t really solve anything practical. If the tools are deemed essential to the software’s workflow, then the software should be helping people use those tools.

You’re coming to this with the assumption that everyone who clicks the download button on .org should be able to test a pull request from GitHub on a Joomla site. I don’t think that should be the case.

Yes, for some people, it is going to be easier to either install Joomla fresh from a package on a pull request or update a testing site using a package on a pull request then trash the entire installation when they’re done. But to me, that is an inefficient use of people’s time.

WordPress doesn’t have all this extra crap. Can’t use a patch file? Too bad. And they are the king of assuming their users are so stupid that PHP and MySQL are considered profane words instead of trusted software.

So, disregard my feedback. The project generally does anyway.

Basically I didn't created this container because it was so much fun, I created because there are requests for this or similar stuff since years and if we can get one tester more to be active we have 10% more test capacity. And no I'm not disregard your feedback.

My stance hasn’t changed over the years. If the tools are too complex for your target user, then the tools need to be changed to match the target user expectations. You’re saying testers are too scared or not savvy enough to use Composer and NPM? To me the solution is to not use those tools, not waste your time, and an entire team’s time, coming up with software solutions that are half assed and don’t really solve anything practical. If the tools are deemed essential to the software’s workflow, then the software should be helping people use those tools.

Once again a tester doesn't need to understand the developer tool chain in my opinion. So we should give the tester the possibility to contribute without being a developer.

If this tool is complete useless we can remove it, it's 10 lines of code.

Define a tester. If they are anyone who is able to download a package from .org and install Joomla on a web server, then you’re 100% correct in that they should be totally oblivious to Joomla’s software development workflow. If that is not the definition of a tester, then understanding what the project’s development lead considers a tester would be beneficial in guiding future work.

Define a tester. If they are anyone who is able to download a package from .org and install Joomla on a web server, then you’re 100% correct in that they should be totally oblivious to Joomla’s software development workflow. If that is not the definition of a tester, then understanding what the project’s development lead considers a tester would be beneficial in guiding future work.

You are right we talk about a completely different group of testers, as already mentioned if you only need to test a UI element in the Backend you don't need any knowledge except how to install joomla. If you want to test the API you still don't need to know our tool chain because you maybe in the python universe and only want to test the webservice. If you want to test a feature in joomla that touches model you should have strong knowledge how joomla works and what this could be affected (if the pr creator didn't mention everything in the instructions).

So yes these builds are for a limited group of persons and should not replace any other testing workflow.

I have read the whole discussion and HLeithner is correct to look at a solution for the Joomla Administrators who are not developers. (Like me)

I can’t use the strange NPM & Composer things, they will certainly not work on the Hosting Packages supplied by different companies.

To make it work on my local device I need a complete manual, which defines every step and support when I get an error.
Most people in user groups want to help and they can if they can just follow a joomla installer or have a always working (or supported if not) patch tester.
I would rather follow the install process to even be able to test that, with an update package to test a fix after confirming the issue in a new install then using the patch tester.

No, @HLeithner should not think this is for just the people who wants a joomla website.

No, @mbabker should not think that joomla administrators are developers or server engineers who understand NPM, Composer or have local systems to use.

@mbabker

My stance hasn’t changed over the years. If the tools are too complex for your target user, then the tools need to be changed to match the target user expectations. You’re saying testers are too scared or not savvy enough to use Composer and NPM? To me the solution is to not use those tools, not waste your time, and an entire team’s time, coming up with software solutions that are half assed and don’t really solve anything practical.

Are you sure your stance hasn't changed? You did maintain the patchtester for years and now you are saying they are a waste of time.

WordPress doesn’t have all this extra crap.

Do they have a larger userbase of technically priviliged coders to help testing?

Define a tester.

The way I see it, we have different levels of testers. The people in like usergroups who can test the easy ones like GUI elements or behaviour. Then there are the people who are familiar with the Joomla codebase and can make a better call whether or not the code is good enough. Finally there is the group of people that can program but don't use Joomla.

I think only the technically privileged should do pull request review and testing (although sometimes I wish that were the case with the number of times I have code reviewed a pull request that was supposedly tested successfully but could have never worked because they introduced different kinds of fatal errors).

If we can only allow full-fledged Joomla developers to test, then we might as well close up shop because we don't even have enough of those to write all the patches.

then understanding what the project’s development lead considers a tester would be beneficial in guiding future work.

Any guidance for the future is welcome :)

@conconnl ask and yee shall receive https://www.youtube.com/playlist?list=PLEBx9wEo0wMJ5jUV5mO8VfIPXdIITIDBK

The way I see it, we have different levels of testers. The people in like usergroups who can test the easy ones like GUI elements or behaviour. Then there are the people who are familiar with the Joomla codebase and can make a better call whether or not the code is good enough. Finally there is the group of people that can program but don't use Joomla.

fully agree. There are countless PRs for small UI elements, and some people are out there who would like to test. But do not understand local environments or forking on github.
Why not involve them in testing if there is a possibility?
I gave up wasting my time for UI tests and running npm.

If we can only allow full-fledged Joomla developers to test, then we might as well close up shop because we don't even have enough of those to write all the patches.

Who is in this group? Sorry to say that but when new contributors make or test PR, the "gurus" should encourage and mentor them instead of demotivate. Who today can test only a border around a table, maybe he or she can test tomorrow the bigger PRs.

Where I agree is that reviewing code can do only by high level developers.

My stance hasn’t changed over the years. If the tools are too complex for your target user, then the tools need to be changed to match the target user expectations. You’re saying testers are too scared or not savvy enough to use Composer and NPM? To me the solution is to not use those tools, not waste your time, and an entire team’s time, coming up with software solutions that are half assed and don’t really solve anything practical.

Are you sure your stance hasn't changed? You did maintain the patchtester for years and now you are saying they are a waste of time.

Patch tester works for what it did in 2.5 and 3.x because Joomla did not rely on build tools. Where it failed was in being a proper patch application system (which, given the name, would imply it's patching files); it did a flat out replace with whatever the file was in the source branch of the pull request because there is nothing in the Joomla installation to be able to calculate a "real" patch, and it inherently ran into the same problems that every pull request has that has a database diff (you can't revert it, you trash the site and either do a fresh install or restore a backup anew). While the component "helps", it masks so many architectural issues with that particular workflow that test results for anything applied with it were flaky at best and downright unreliable at worst.

WordPress doesn’t have all this extra crap.

Do they have a larger userbase of technically priviliged coders to help testing?

I am not aware of who does testing in their ecosystem, or what Automattic's requirements for testing of a patch are before it is accepted into WordPress, or the challenges those people may or may not face. All I am aware of is they don't have things like the now abandoned pull request testing platform or the patch testing component or a system that generates installable builds for every patch, and they have been utilizing NPM based tooling for quite some time longer than Joomla 4 has stopped committing those resources to its source code branch.

I think only the technically privileged should do pull request review and testing (although sometimes I wish that were the case with the number of times I have code reviewed a pull request that was supposedly tested successfully but could have never worked because they introduced different kinds of fatal errors).

If we can only allow full-fledged Joomla developers to test, then we might as well close up shop because we don't even have enough of those to write all the patches.

Thanks for quoting my comment out of context, very conveniently leaving the "It’s not because" opening to that sentence out of your quote. But since we're here and you're taking my words out of context, let me make a statement that goes along with your chosen context. The groaning about how hard it is to test Joomla didn't exist until Composer and NPM were introduced. The groaning wasn't there before. So either people accepted the fact that to properly apply a patch you either needed git (SVN before that) or you needed to be able to manually edit files. What that tells me is the way Joomla has introduced the tools is fatally flawed and that Joomla either needs to tell people to get with the times and learn the tools or Joomla needs to stop using the tools. Yes, I am aware that opinion makes me an asshole by telling people either learn the software or stick to the things their skillsets allow them to do, or by telling the software leadership that their decision making processes are garbage. I don't care.

====

This is my last reply on this thread, then I'm back to ignoring 85% of the things on here.

I seriously don't agree with Joomla saying "we're going to use all these tools for Joomla's development environment, but to contribute to Joomla's development environment, we are also going to create even more tools to hide the tools". This is essentially you all saying "we think the barrier to contributing is too high, but instead of lowering the barrier, we're just going to paint the barrier all fancy like and make it look good". This is the wrong approach to fixing the problem you all seem to have identified, but if you all are really OK with continuing to rely on broken mechanisms for developing Joomla (including the lack of rollback for database schema changes or the fact that nobody seems to care about a well architected automated testing suite outside of paying lip service to it), then by all means keep on doing what you all are doing.

i'm in two shoes here
shoe 1
learn peoples on how to fish
shoe 2
give them fish/food

Well lets have another point of view where this can be useful.

We just build an system test that updates 3.10 -> 4.0 nightly. With some more things (we need an xml file in a predictable location) it should be possible to run the system tests on every 4.x PR.

So we know that this 4.x PR does not break the update

I think this is a good improvment. Npm and Composer is the hell. Many Times it works but when it don't Work i dont't know why.

nowdays git, composer and npm are pretty well like industry stadards we cannot ignore them
the only thing we can do more is to educate people on how to use them

The way I look at npm is like a racecar. Most people can drive a car and only few will succeed to drive a racecar no matter how much you educate them. NPM is a specialist tool and not one for the masses.

i mean at least just for testing pr's is it not rocket science (even if i'm a dumb with npm /js etc)
you just need few info to have it installed in your localhost (win/linux/mac/docker) or whatever

@alikon you are right when npm and composer works right but from time to time it don´t work. And then, people like me we can´t test pr´s.

I've never had it not work

@brianteeman then you are e lucky guy or you have the necessary skills.

Thats only my 2cent. I´m out!

that's why i'm still in 2 shoes,
there is no lucky guys,
is it only bad communication/documentation
we need a better way to communicate how to do things step by step in a better way

What would be really helpful would be if that when someone says "it doesn't work" that they tell us and tell us the exact error.

I've never had it not work

What would be really helpful would be if that when someone says "it doesn't work" that they tell us and tell us the exact error.

An anecdote of a backbencher:

I needed 2 weeks (instead of testing) before my first composer and/or npm environment ran on my local machine NEARLY without hundreds of quickly disappearing lines with messages, warnings, errors telling this or that shit.

I first had to learn the ideas behind composer and npm before I understood how to fix this or that issue.

And I'm one of the lucky guys that have learned to configure Linux machines on a console in the past and knows how to update this or that version. I ended with a Debian WSL after trying other distributions = another week gone, tried to restore my old Linux server and so on. But nobody told me that. I had to find my own way. Just to test J4 patches.

In the beginning I planned to provide a documentation for WIN/WSL users and gave up in the end because the 100s of lines with my HowTo notes were confusing BS.

Theoretically I was now at a point where I could test a J4 patch. I did it once ;-) and never came back ;-) because the next chapter was opened for git to test several patches in one work flow with restoring the Joomla base after each test.

On the other hand I won't come back for J4 testing (when not possible with PatchTester) if I have to make new installations for any patch. That's something that people can quickly do that work with environements that tell me that these people don't need these per-pr-install-packages at all.

On the other hand I won't come back for J4 testing (when not possible with PatchTester) if I have to make new installations for any patch. That's something that people can quickly do that work with environements that tell me that these people don't need these per-pr-install-packages at all.

As you can install the zip patch and than (excluding PRs with database changes) just hint the "reinstall" button it is not required to do a per patch install.

As you can install the zip patch and than (excluding PRs with database changes) just hint the "reinstall" button it is not required to do a per patch install.

but the Re-Install button provides only the previous status of 4.0.0-dev - no sql update files.
I think so.

This is why i said (excluding PRs with database changes). There is no revert to version X feature yet in joomla ;)

Since there is still the question if this pr is useful I added 2 things to the docker image.

1. Add an update manifest for easy update testing
2. Add a landing page with information and warnings for easier use

Based on point 1. the update test of tobias can use this ready to install packages for update tests.

If this container works I will port it to staging and 3.10

how to test?

how to test?
When packaging is ready the link will be an entry "download" in the checks section. For the current build:

https://ci.joomla.org:444/artifacts/joomla/joomla-cms/4.0-dev/28409/downloads/30563

For the last (unsigned) build the url is:
https://ci.joomla.org:444/artifacts/joomla/joomla-cms/4.0-dev/28409/downloads/30560

The first of those links gives a 404

As for the text on the second page and the menu links. Where can that be edited as its neither english nor logical

As for the text on the second page and the menu links. Where can that be edited as its neither english nor logical

https://github.com/joomla-projects/docker-images/blob/packager/templates/index.html

Thanks @wilsonge I will give it a go tomorrow

First link is ready in the meantime, the text is copied and (pretty sure not good) modified from https://developer.joomla.org/nightly-builds.html

@HLeithner Am I correct in assuming that the target user of this is the less technical user? If I am then the text needs completely rewriting as its targeted at developers. Builds, commits, pull requests are meaningless to the target user

@brianteeman I would be happy if you write a better text and make a PR against https://github.com/joomla-projects/docker-images/tree/packager

started a pr

I'm merging this now in for 4.0 thanks @HLeithner for this great work to make the life of our testers and automated tests even more easy where possible. ?

Also thanks from me to @HLeithner for your great work!
Even, I didn't understand all technical features :-)

I will install (again) a fully nightly. Should I use this one? https://ci.joomla.org:444/artifacts/joomla/joomla-cms/4.0-dev/28409/downloads/30563/

You can but in the best case you install the nightly from here: https://developer.joomla.org/nightly-builds.html

silly question
is this feature working for the pr that have been submitted/changed after this has been merged ?
so no download package+pr for the oldest ?

as an example this pr #27005 doesn't have the download link

@alikon just retrigger drone ?

Just wanted to say the same ;-)

i didn't have that super power ?

plus shouldn't we need to trigger a batch task for trigger drone for all the oldest pr's ?

People would need to update their branch to the latest 4.0 to have this in their drone configs before you reran. I don't think it's worth the effort. just let it be phased in.

this doesn't help the peoples for which this pr was intended for