I have retriggered a failed Travis-CI build for a public open source project yesterday. The build succeeded, however, the badge still shows "build failing", both on GitHub and on Travis-CI.
Is there anything I can do to refresh it?
The previous answer is so close! Github wouldn't be involved at all, all they do is link to the image with html. And I know from experience that Travis updates it basically immediately. It's actually browser side caching!
Your browser doesn't request the new image because it already has it. This is actually how all images work on the web. You can rest assured the correct build status is showing for new visitors to your repo.
If you need that green badge to show up for your own peace of mind, just hit Ctrl+F5 to purge the cache.
Not sure about Travis-CI, but I know GitHub aggresively caches images. Once the cache goes stale you'll see the correct badge. Other than waiting there's not much you can do.
Command+Shift+R in Chrome on Mac solved this issue for me
As #icodesometime answered, it's more to the client's browser caching problem, dealing with the CDN's cookie.
If you get even passing the TravisCI and reloading doesn't take effect, such as hitting F5 or Shift + reload or Control + F5 etc. in Chrome, then try:
Open Developer tools
Right-click on the reload/refresh button and select "Empty Cache and Hard Reload"
I just discovered that you can "bust" the GitHub cache by just adding insignificant content to the URL query string. So while "https://img.shields.io/travis/numpy/numpy/master.svg" might be cached, "https://img.shields.io/travis/numpy/numpy/master.svg?x=1" probably isn't. Or add "&x=1" at the end if there is already query string content. Works for me for every badge type. Note that you will want to change the value in that query string every time you need to bust the cache.
Related
Explanation
I'm having an issue with Workbox where my website doesn't update when a file's content is changed, unless I manually clear storage/site data in my browser.
Since v4 release this year, the cleanupOutdatedCaches, which is in my code, should take care of this, but the problem persists.
Example
I created this website to exemplify. Once you access it, Workbox will install the service worker, but if I change, for example, test1 to test2, you won't see the change, unless you clear the site data in your browser and refresh.
I also tried only unregistering the sw; it shows the updated version (test2), but when refreshing twice it goes back to the old version (test1).
You can see the website's code in GitHub here.
Thanks in advance,
Luiz.
cleanOutdatedCaches will only clean caches created by older versions of the workbox library. In this case, since you are using the same version fo workbox, the call to this method does nothing.
https://developers.google.com/web/tools/workbox/reference-docs/latest/workbox.precaching#.cleanupOutdatedCaches
Once a particular file is precached by Workbox, it will never attempt to retrieve that file from the network, unless the revision you have specified in the precacheAndRoute call is different from what was previously cached.
Since you changed index.html but not the revision in precacheAndRoute, workbox assumes the file is unchanged. So,what you need to do is to update the precacheAndRoute with a new hash that corresponds to the new version of index.html
You can achieve this by either using injectManifest
https://developers.google.com/web/tools/workbox/modules/workbox-build
or any other build tooling you use.
Edit:
You can invoke skipWaiting programmatically as well
https://developers.google.com/web/tools/workbox/modules/workbox-core#skip_waiting_and_clients_claim
But you do need to use it with caution. Here is one way to do it :
https://developers.google.com/web/tools/workbox/guides/advanced-recipes
Let me say first that I'm quite new and inexperienced with rails. Today I tried to update an image in a rails app hosted on Heroku. Anyway, this is the simple flow I followed as I did other times before:
Add updated image to the image folder
Precompile the assets rake assets:precompile
Add and commit all changes
Push to heroku
Until this point all seems fine: I open Chrome to check my app from my domain and it's all there as expected.
The problem is that if I refresh the page all the images disappear (like they have never been loaded). This does not happen locally.
If I do a ctrl+f5 it all comes back nicely, but I lose everything again on simple refresh.. and so on.
Has anyone experienced something similar? I understand this might be hard to answer as there is not much code to show. Let me know if I can give more details.
On a final note, it seems that all works normally on a friends machine (that is, refresh doesn't give this problem). I'm thinking something might be wrong with my Chrome settings here? I don't remember having changed anything recently though.
This is very weird and quite annoying some help/insights would be great.
UPDATE: This seems indeed really to happen locally on my machine at work. I checked from another couple of computers at home and the app is displayed fine (without any refreshing problem).
Did you check if the cookie is disabled by your browser for the heroku website in particular?
I have just tested this issue with an image based website (https://unsplash.com/). When the cookie is disabled for that website, pressing F5 clears all the images, while pressing Ctrl-F5 brings those lost resources back as like as your case.
Enabling cookie resolves the issue in my case.
I am using Umbraco 7.5.2, installed on a VM in Azure.
When a Publish At date is set, the page is never published. I have tried the following steps.
Create and publish a page
Unpublish the page
Set the Publish At date to a few minutes in the future and Save&Publish
Verified page is definitely not visible
Wait for the time to roll around, and even a few minutes more
Page is never published.
The following message appears in the logs on save when setting the publish at date, which is normal. But no other messages appear after and the page is never published.
2016-10-25 17:46:20,784 [P4808/D10/T21] INFO Umbraco.Core.Services.ContentService - Content 'Video1' with Id '1312' is awaiting release and could not be published.
I've made a copy of my production Umbraco folder and of the database ON THE SAME VM. That instance works for scheduled publishing.
I'm wondering if anyone can provide some clues as to what the issue could be or where I could look. I'd like to avoid having to migrate my production data to this test site.
Thanks
The problem may be related with different time-zone on azure VM as Umbraco is using server time to proceed inside the code execution. This should be the first thing to check.
In version 7.6.0 (https://our.umbraco.org/contribute/releases/760) it will be possible to set up server timezone and then set up a time with precise offset, so those type of problems shouldn't be seen then.
For me it was a wrong umbracoApplicationUrl path (it has to point to YOURDOMAIN/umbraco) After fixing this url everything started working fine
In addition to Marcin's answer, also check that the server can access itself, as it pings itself to fire the scheduled publishing. If it can't resolve it's own address, the scheduled publish will fail. It doesn't happen often, but I've seen a few VERY locked down installs where the server can't resolve it's own address.
Several times a day I receive this error while running my asp.net mvc4 project. I am not asking what that means, or how to fix it, but what am I doing to cause it? It is really starting to bug me, and if I can cause it to go away by altering my workflow I will.
Cannot create/shadow copy '< assembly >' when that file already exists.
As I mentioned above the project is an MVC4 application. My workflow is typically.
Make a change (code or html)
If it was code, rebuild the project (using keyboard shortcut CTRL+SHIFT+B)
refresh the page
see annoying error
clean the solution
rebuild solution
refresh page
verify change
goto 10
(I get the error with/without the debugger attached.) I will be eternally grateful to anyone who can inform me on how to avoid this error, and will promptly tweet your praises
I find this annoying too. It seems to happen when you try to refresh the page in a browser before the build is fully complete. Try counting to three-one-thousand after build is complete and then refresh in the browser. Create/shadow copy should be done by that point.
I also don't think you should need to "clean solution". I believe a rebuild is a clean + build, so you may be cleaning twice.
After a bit of research, I also found this pre-build event which seems to be popular. (this workaround does not seem to work, perhaps it did in previous versions of VS / .NET framework)
Update: alternate solution
Another way to get by this is, when you see the YSOD, just type in a different URL in the browser and load it instead. Then click the back button and refresh to get to the page you were trying to reload in the first place.
What's causing this error seems to be doing the shadow copy (stating the obvious...), ie generating a file in one folder and then reading it to copy it elsewhere. I think what's causing the issue is generating or not that first file, and when/how it's copied, regardless of what your actions are. Does this first file (that will be shadow copied) needs regenerating, and therefore re-shadow copied?
This post says:
By default shadow copy is enabled on every appdomain created by ASP.NET. Assemblies loaded will be copied to a shadow copy cache directory, and will be used from there. So that the original file is not locked and can be modified.
And their fix is to prevent shadow copy. But I don't personnally fully understand what shadow copy does in the asp.net context, maybe someone can clarify if there are any bad side effect to disabling it:
<configuration>
<system.web>
<hostingEnvironment shadowCopyBinAssemblies="false" />
</system.web>
</configuration>
This post talks about disabling indexing and/or antivirus, which would suggest that building the project generates new files, and the antivirus (or indexing service) accesses them and locks them, just when the shadow copy is trying to copy that exact same file.
I get his error regularly and never found what specific action I do causes the error. I make a code change, press F5 (Run/ Play button), get the error in the web browser, close the web browser, press F5 again. It now works. I don't clean, I don't rebuild. However, with the second F5/Run, I believe VS detects there's been no code change, and therefore, maybe the shadow copy is not redone? Or maybe this time the shadow copy is timed slightly differently and it works.
I received this error after adding a new image to my web project.
In VS, each image has a property entitled "Copy to Output Directory". I chose "Copy Always", then I got the message.
I changed it to "Do Not Copy" - now it is happy.
Hope that helps someone.
I'm using the Facebooker plugin in Rails to publish a user action to their newsfeed, but the image isn't being added.
The call (via Net::HTTP.post_form) looks like this:
Posting to http://api.facebook.com/restserver.php with
{:api_key=>"4f5ed28f76142adsfasdf029c98ad", :template_bundle_id=>"107345673712",
:template_data=>"{\"project\": \"testing\", \"images\":
[{\"src\":\"http://www.dezyne.net/news.jpg\",
\"href\":\"http://www.facebook.com/\"}]}",
:session_key=>"2.nvhdfsdfgimDZWSwQ__.86400.1245405600-100000007614297",
:method=>"facebook.feed.publishUserAction", :sig=>"ac0a7181b351b5fdgsdfge767a004314",
:call_id=>"1242343866.44512", :v=>"1.0"}
'Project' is captured OK in the text that's posted to the newsfeed.
One possible issue is that you tested this template before actually uploading the image. This would cause Facebook to have cached an empty image. Every time the image is requested, FB uses their stored cache rather than retrieving the image all over again.
If this is the problem, the solution is to use the API function fbml.refreshImgSrc() to cause Facebook to update their cache. Unfortunately there's no quick mechanism to do this as that API method is not available in the Test Console nor through the Developer app at all, meaning you will need to write a script just to refresh the cache of this image.
If this doesn't help, post back and I'll see if I can't think of any other possible problems.