Skip to content
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

Wrong badge status in README.rst file, but correct status in RTD documentation #4557

Closed
vcalderon2009 opened this issue Aug 22, 2018 · 7 comments
Labels
Bug A bug Operations Operations or server issue

Comments

@vcalderon2009
Copy link

Details

Expected Result

Build status badge on the README.rst in the root directory shows up as "Failed" (Displaying as red color). However, the builds are passing and I was able to see the correct
documentation.

Actual Result

Build status badge color is displaying as red on the README.rst file in the root directory, even when the builds have passed and the documentation was properly built. When I look at it on Github, it shows up as red. However, when I go to the documentation, it the "docs" badge is green as says "passing".

I tried rebuilding the documentation, rearranging links, but I haven't had success yet.

I have also tried to put the link on a "badge_test.md" file (in root directory) without success. I literally copied and pasted the badge link from RTD for markdown.

I wanted to know if anyone else has this issue, or if anyone has an idea of how to fix it.

@stsewd
Copy link
Member

stsewd commented Aug 22, 2018

The problem is that github is caching the badge internally with a control-cache header with max-age=31536000. The badge does have a contro-cache header, but it redirects to the new azure storage https://rtdcommunitypublic.blob.core.windows.net/static/projects/badges/passing-flat.13d664e1afd7.svg, which doesn't have a control-cache header, I suppose that there is the problem, I think this can be configured in azure some how.

@stsewd stsewd added Operations Operations or server issue Bug A bug labels Aug 22, 2018
@vcalderon2009
Copy link
Author

vcalderon2009 commented Aug 22, 2018

Thanks for the insightful comment. In that case, do you know if that is something that I can fix on my end? Or are Github/Microsoft the only ones with the ability to fix the caching-issue?

@stsewd
Copy link
Member

stsewd commented Aug 22, 2018

Sadly there is nothing users can do here, hope the rtd team can find the setting to fix this in the Azure storage.

@vcalderon2009
Copy link
Author

That makes sense. In that case, I'll wait and hopefully it can be fixed.

But thanks again!

@humitos
Copy link
Member

humitos commented Aug 22, 2018

Just linking some prior art on this, #3323

@davidfischer
Copy link
Contributor

As @stsewd suggested, the final URL (https://rtdcommunitypublic.blob.core.windows.net/static/projects/badges/passing-flat.13d664e1afd7.svg) does not set the cache control header.

I see two oddities here but hopefully we can resolve them quickly. Firstly, the code to handle redirecting to the badges uses an undocumented (as far as I can tell) method in the staticfiles app. This should probably just use settings.STATIC_URL instead and the final URL should be https://assets.readthedocs.org/static/projects/badges/passing-flat.svg`.

>>> from django.contrib.staticfiles.templatetags.staticfiles import static
>>> from django.conf import settings
>>> settings.STATIC_URL
u'https://rtdstoragetest-media.readthedocs.io/static/'
>>> url = 'projects/badges/passing-flat.svg'
>>> static(url)    # notice this output URL doesn't match STATIC_URL
'https://rtdstoragetest.blob.core.windows.net/static/projects/badges/passing-flat.13d664e1afd7.svg'

Secondly, it looks like the cache-control header on the underlying storage (which if it goes through STATIC_URL might be the Azure CDN rather than Azure's blob storage) must be set.

@davidfischer
Copy link
Contributor

Just linking some prior art on this, #3323

This is almost certainly related. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug Operations Operations or server issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants