Dear Michael,

On Mon, Mar 10, 2014 at 01:29:26AM +0100, Michael Schumacher wrote:

[...]

How it works
------------

Our web host, cube.gtk.org, is set up to check the branch for changes every five minutes; and if there are any, pulls them and builds the site into the document root of the http://testing.gimp.org site.

If this works well, I'll set up the same for http://www.gimp.org

Any way we can do this with http://docs.gimp.org too?

Currently I do have to update it manually and it'll be such a boon for doing that automatically.

Cheers,

Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org

On Tue, Mar 11, 2014 at 09:57:39AM +1000, Roman Joost wrote:

Dear Michael,

On Mon, Mar 10, 2014 at 01:29:26AM +0100, Michael Schumacher wrote:

[...]

How it works
------------

Our web host, cube.gtk.org, is set up to check the branch for changes every five minutes; and if there are any, pulls them and builds the site into the document root of the http://testing.gimp.org site.

If this works well, I'll set up the same for http://www.gimp.org

Any way we can do this with http://docs.gimp.org too?

Currently I do have to update it manually and it'll be such a boon for doing that automatically.

Having said that tho, since my question was only related to the documentation website, it might actually be better to scrap http://docs.gimp.org and simply keep everything under:

http://www.gimp.org/docs/

We've always maintained this redundant information, but there is not much more to find on http://docs.gimp.org than what we have under above wgo URL.

Any objections? Comments?

Cheers,

Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org

On Wed, Mar 12, 2014 at 01:35:46AM +0100, Michael Schumacher wrote:

On 12.03.2014 00:21, Roman Joost wrote:

Having said that tho, since my question was only related to the documentation website, it might actually be better to scrap http://docs.gimp.org and simply keep everything under:

http://www.gimp.org/docs/

http://docs.gimp.org is established; if we change anything we should remove the duplicate content from www.gimp.org/docs and replace it with a link to the docs.gimp.org site.

True as well. I actually have that on our roadmap. It just seemed to be such a straight forward idea. What were I thinking ...

Kind Regards,

Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org

On Wed, Mar 12, 2014 at 01:31:57AM +0100, Michael Schumacher wrote:

On 11.03.2014 00:57, Roman Joost wrote:

On Mon, Mar 10, 2014 at 01:29:26AM +0100, Michael Schumacher wrote:

Our web host, cube.gtk.org, is set up to check the branch for changes every five minutes; and if there are any, pulls them and builds the site into the document root of the http://testing.gimp.org site.

If this works well, I'll set up the same for http://www.gimp.org

Any way we can do this with http://docs.gimp.org too?

If we've got the necessary dependencies there - for the website, those are next to none, i.e. Python 2.4 with its standard modules.

All we need is docbook web stylesheets and that is it. A simple:

make

in the 'web' directory will produce the necessary HTML files under web/html.

Always doing this manually and then copying it to cube makes me cringe. For the docs website changes are not that often, so we could even get away with just updating the site with changes under gimp-help-2/web.

Kind Regards,

Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org

Hello,

It would probably make sense to put "Disallow: /" in http://testing.gimp.org/robots.txt

On Mon, Mar 10, 2014 at 1:29 AM, Michael Schumacher wrote:

Hi,

as a first step to get http://www.gimp.org built automatically from the gimp-web master branch, I've created a testing site and a testing branch:

http://testing.gimp.org (as you can see, it lacks the news items from www.gimp.org - those are the only dynamic part of the site)

https://git.gnome.org/browse/gimp-web/tree/?h=testing (pretty much indistinguishable from the master branch)

See the following pages for info about how to check out this branch and have it track its remote:

https://wiki.gnome.org/Git/Developers#Using_Branches http://git-scm.com/book/en/Git-Branching-Remote-Branches#Tracking-Branches

How it works ------------

Our web host, cube.gtk.org, is set up to check the branch for changes every five minutes; and if there are any, pulls them and builds the site into the document root of the http://testing.gimp.org site.

If this works well, I'll set up the same for http://www.gimp.org

-- Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD _______________________________________________ gimp-web-list mailing list
gimp-web-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-web-list

A simple solution would be to remove this file from git. What security does it provide? It only shows "attackers" where is the admin URL, which can be helpful.

Another option is to simply modify the file on testing.gimp.org. If robots.txt is not modified, then everything will be fine. If it is modified at some point (unlikely), git pulling/pushing will fail, which is exactly what you want, so that you can update the file on testing accordingly.

Your two options sound good too, you just need to make sure that this does not bite you later on, eg. if the branch name changes or if the git hook is removed for some other reason.

On Fri, Mar 14, 2014 at 11:05 AM, Michael Schumacher wrote:

Von: "Quentin Pradet"

Hello,

It would probably make sense to put "Disallow: /" in

http://testing.gimp.org/robots.txt

Yes, good idea.

What is the best way to have this on the testing branch, and never merge it back to master by accident:

- a local git hook on cube to have it create that file on the fly? - a make rule to do this, based on the branch name?

-- Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD _______________________________________________ gimp-web-list mailing list
gimp-web-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-web-list

Perhaps a separate environment repository where configs specific to the environment get overwritten during the "build" process using rsync.

e.g. I have Test, Prod, Dev branches in a project. Each environment has specific files which need to be tracked but must be different across all. So I have a config repository as a git submodule with the following structure...

env-config/Test/Robots.txt env-config/Prod/Robots.txt
env-config/Dev/Robots.txt

In each env-config/ it matches the directory structure of my repository so I can simply do the following to overwrite during the build process...

rsync -av ./env-config/Test/ ./

Just a thought.

---- Also, are any of the web dev's interested in me pointing my QA tester at the test site? [1]

[1]: https://github.com/sag47/chewbotkah