#3387 closed defect (fixed)
Chef is not baking my updates
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | Website Management, Bots |
Component: | website | Version: | master |
Keywords: | Cc: |
Description
I think there is something wrong with our chef configuration or the subversion pull. Not sure which.
I made updates to this page several days ago:
http://postgis.net/windows_downloads/
To show winnie's new build badges. The page still has not changed.
Change History (16)
comment:2 by , 9 years ago
Owner: | changed from | to
---|
comment:3 by , 9 years ago
Owner: | changed from | to
---|
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Deleting the _cache folder wasn't good enough. I had to delete the _counter folder as well and then rerun the bash script.
I'm guessing maybe it's not overwriting counter files if it sees them present. Anyway I'll consider this fixed for now and investigate why pages remain stale some other time.
comment:5 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Okay my release post needed some help to post.
I had to delete the _counter folder and then rerun the sh script. Not sure why that doesn't work on its own.
Seems to be an issue with the blog posts presumably because they get stitched into the frontpage and other places.
Further investigation required. I guess we could just wipe out the _counter folder as part of the sh script since the build is under 30 seconds anyway.
comment:6 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Added line
rm -rf counter
to the postgis_website_update.sh script
Full script is now:
cd /var/www/postgis_website /usr/bin/svn -q update rm -rf _counter ./_piecrust_1.2.0/bin/chef bake chown -R www-data:www-data _cache _counter
comment:7 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Sadly now this gives a 404 - http://postgis.net/tips
Don't know how my little change broke this.
comment:9 by , 9 years ago
I thought I fixed by moving the rm line above svn update but that didn't do it, had to take out completely.
postgis_website is owned by root but _counter and _cache are owned by www-data. I just don't understand why removing it is a problem since the bake step recreates it anyway. Maybe some sort of parallelism is that possible? I noticed if I manually run the script with the rm line in there, it complains about not being able to set ownership of some folders.
comment:10 by , 9 years ago
Creating a directory requires write access on the parent directory. Does baker run as "www-data" ? Try removing the contents instead (rm -rf _counter/*) -- note I've no idea why you are removing that dir, FWIW.
comment:11 by , 9 years ago
Baker runs under root so don't see why it wouldn't have access. I'll try removing contents instead and see if that does the trick.
comment:12 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Okay that might have done the trick. I tried running a could of times and things still seem to be there. I'll close for now.
comment:13 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:14 by , 9 years ago
okay this was still an issue if I have even rm -rf _counter/* in there , it goes south and blog entries don't come back.
I'm going to assume that this is a bug in chef or the extra duplication we have of junk from chef. So I revised the script to bake twice after _counter remove stuff, so it now looks like this:
cd /var/www/postgis_website rm -rf _counter/* /usr/bin/svn -q update #rm -rf _counter/* ./_piecrust_1.2.0/bin/chef bake #for some reason baking once is not enough to bring back _counter ./_piecrust_1.2.0/bin/chef bake chown -R www-data:www-data _cache _counter
running manually seems to work okay. I'll close this out if on regular run it doesn't screw things up again.
comment:15 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
My last post http://postgis.net/2016/03/13/tip_pixels_of_range_value/ went thru without breaking anything so guess it's working now with the double bake.
I should add, I tried manually running the postgis_website_update.sh script and it didn't seem to help.
Actually that file is where changes show, but the actual files changed are these: https://trac.osgeo.org/postgis/browser/web/_content/posts/1950?order=date&desc=1