-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[4.3] Fix broken package build after merge of PR #39374 #39408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4.3] Fix broken package build after merge of PR #39374 #39408
Conversation
|
I have tested this item ✅ successfully on 657b6de This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39408. |
1 similar comment
|
I have tested this item ✅ successfully on 657b6de This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39408. |
…build-after-pr-39374
|
RTC This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39408. |
|
To be honest, I love this PR's description and documentation. Thanks Richard @richard67, you made it easy to test. |
|
It should go without saying but removing assets is a B/C break. |
I will agree for |
Even if this was true for the assets handled here, this PR just removes them from the json but not from the file system on update. That is done with my other PR #39401 . So the thumb down should go there and not here. |
|
It's actually this PR that causes templates to error. |
So we shall keep not existing asset files being referenced in the assets.json? |
He's suggesting reverting the changes in the |
@dgrammatiko "the parent PR will break any existing override." ... does that mean we should revert #39374 ? And regarding the "adding a simple check on the versioning script": If you can make a PR for this, I'd close this one here. But then we should add some comment to the json with that PR which tells why we have these not existing assets in it. And what should I do then with my PR #39401 ? Should I revert the last commit so the files are not deleted on update? |
No, the B/C promise allows these kinds of breaks. What I just realised from @SharkyKZ 's comment is that if you manipulate the assets.json and remove an entry the WAM will throw a PHP exception. This should never be allowed! About keeping or removing the files I guess the maintainers should decide on this. But I think @SharkyKZ unveiled something interesting about WAM and the jsons and probably this worth some revision of the B/C promise and set some restrictions so layouts never throw... |
@dgrammatiko I've pinged the other maintainers in the maintainers channel on Mattermost and hope someone can have a look on it and make a decision. Thanks for your support so far. |
|
Back to pending due to discussion. See details in previous comments. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39408. |
@richard67 here are the changes for the versioning:
to let jAssetFile;
try {
jAssetFile = await lstat(path);
} catch(err) {
final[directory].push(asset);
return;
}About the other questions: I'll say wait for the maintainers |
|
@dgrammatiko Ok, if you are busy I can make the PR for the versioning js and mention you, and then close this one here. We have discussed on Mattermost, and it seems that will be what we do as first, leave them in the assets.json. For the long term it would be good to have a kind of deprecated logging for obsolete assets. |
|
Closing in favour of #39413 . Please test. Thanks all. |
Pull Request for Issue # .
Summary of Changes
After PR #39374 has been merged, the package build e.g. with
php ./build/build.php --remote=HEAD --exclude-gzip --exclude-bzip2fails at the versioning step for the assets because PR #39374 has removed some JS but hasn't removed it from filebuild/media_source/com_users/joomla.asset.json.This PR here fixes that.
It was partly also my fault. I should have noticed this when reviewing that PR, but well, nobody's perfect.
But when testing the PR it was not obvious because package building doesn't belong to our usual testing instructions and also not to the automated CI tests, and the package build which drone runs for building the testing packages seem not to include that versioning step because it hasn't failed for that PR. Everything was green.
Pinging @Hackwar just for information.
Testing Instructions
It requires a development environment (Git clone of this repo, composer, npm) either on Linux or on Windows with WSL to run the build.php script.
php ./build/build.php --remote=HEAD --exclude-gzip --exclude-bzip2.Result: See section "Actual result BEFORE applying this Pull Request" below.
git clean -d -x -fandgit checkout ..git fetch upstream pull/39408/head:test-pr-39408and thengit checkout test-pr-39408.Result: See section "Expected result AFTER applying this Pull Request" below.
Actual result BEFORE applying this Pull Request
At the end of the output in the command window:
Expected result AFTER applying this Pull Request
At the end of the output in the command window:
Link to documentations
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed