Update jquery-ui-rails version to 4.1.1 #5380
Conversation
|
How did you verify that the gem update fixes the bug if you couldn't re-produce it? I think you would need to pre-compile assets on your local machine and change the code to not compile them on-the-fly in development to re-produce this error. You'll find the options in At least I can re-produce this in staging:
That 404 error needs to be gone. |
Cool. Thank you for showing how to reproduce the error. I will check it out at my side :) |
Looks like we have some easy steps for a tester to verify 👍 I've updated the testing notes in the PR description. |
There was a problem hiding this comment.
👍
I made a mistake in #4839 I should have told dependabot to "ignore this major" but I said "ignore this dependency" so dependabot didnt try this minor upgrade.
Poor @dependabot doesnt understand when humans make mistakes when talking to it :-)
Anyway, I have reopened 4839 to see if I can get dependabot to try by itself to upgrade to 4.2.0 or even 5.0.5, they may work even if 6.0.1 didnt.
Meanwhile we can go ahead with this PR 👍
| railties (>= 3.0, < 5.0) | ||
| thor (>= 0.14, < 2.0) | ||
| jquery-ui-rails (4.0.5) | ||
| jquery-ui-rails (4.1.2) |
There was a problem hiding this comment.
the upgrade is actually to 4.1.2 right?
I guess the gemfile can have 4.1.2 instead of 4.1.1?
There was a problem hiding this comment.
@luisramos0 Yes. It looks like it is using 4.1.2 even it is told to upgrade to 4.1.1 . I can change this .
|
I tried testing it locally. I manage to tweek the
How are the haml files being compile? |
|
Seems like I screw up the precompile assets. I cleared them out and re-compile again. This time, there is no error and I used the same way that @mkllnk said.
I not too sure what to do to re-produce in my local :( |
|
Did you delete your compiled assets and re-compile them before testing with master? Otherwise it will probably find the asset that was compiled (copied) in your fixed branch. Anyway, it's a good upgrade anyway so we'll test this in staging. |
|
@mkllnk Yes.. I did clean the compiled assets and re-compile it. |
|
Hi @ckhung5, I followed @mkllnk's test procedure, and checked the 404 error on requesting the file: Before the PR: the 404 error, is visible, but: after the PR: the erro 404 r is still visible. The request for the file /assets/spinning-circles.svg seems to be gone, after the PR. I found no issues on a basic sanity check, but from the pics above, I am not entirely sure the PR solves the issue... Thoughts? |
|
@filipefurtad0 this PR is just upgrading a dependency so, if, from your perspective, nothing is worse than before, we should merge. If the issue is not solved we can keep the issue open. |
|
Hi @luisramos0, The testing notes led to the comment from @mkllnk #5380 (comment) above, which states "That 404 error needs to be gone.", hence my doubts here. But I did not find loss in functionality, so I think this is good for merging. |
|
Hi @filipefurtad0 . Pardon me for asking. Do you do a It is very odd that I can't reproduce the error. |
|
@ckhung5 Testing happens on our staging servers. They are similar to the production environment and don't use Docker... |
What? Why?
There are some noise about assets not found related to jquery-ui-rails gem.
Relates to #5201 but doesn't solve it.
This change will solve the noise for unable to findui-bg_flat_75_ffffff_40x100.png. This is a bug in the gem itself and they introduce adepend_onas mentioned in jquery-ui-rails/jquery-ui-rails#59 and jquery-ui-rails/jquery-ui-rails#60.So we only just need to update jquery-ui-rails to version 4.1.1
What should we test?
Steps to reproduce the bug here: #5380 (comment)
We should also do a sanity check on admin datepickers and dropdowns with search fields.
Release notes
Update jquery-ui-rails version to 4.1.1 to introduce some depend_on assets in the gem as there are currently some assets errors in the application.
Changelog Category: Fixed