655715 - dev or stage markup.allizom.org Help with git and jinjo update

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Austin King [:ozten]]

Subject: Cron <root@mradm02> /data/engagement-dev/python/markup.mozilla.org/update > /dev/null
Body:
warning: unable to rmdir src/jingo: Directory not empty
fatal: Unable to create '/data/engagement-dev/www/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
fatal: Unable to create '/data/engagement-dev/www/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

Comment 1

[Austin King [:ozten]]

I'm getting this cron mail every 15 minutes. 

I think I need help with the new jinjo submodule on markup-lib.

I don't know which environment is generating these email, probably markup-dev based on the path /data/engagement-dev/www.

Comment 2

[[:brez]]

This is a permissions issue on the server itself (i.e. nothing to do with git submodules - I reviewed your addition of jingo, it looked good) - what likely happened is someone used sudo where they shouldn't have and set the git index to root permissions, now the deploying user can't update the index and fails.. 

I'm still hoping to get access soon - but in the meantime just hit me up in IRC and I can walk you thru it..

Comment 3

[Justin Dow [:jabba]]

It's not a permissions issue. The server doing the checking out from github is all doing it as root.

The lock file issue might have been where I was running the update script by hand at the same time that cron was firing it off.

The issue with the submodule update init trying to rm the src/jingo directory could be a problem with my update script. I'm obviously still having a hard time trying to get a working one put together. I've modified it over and over again to try to get it right. I'll paste it here in its current form, perhaps someone could fix it and paste/attach what a proper auto-update-from-github script should look like...

#!/bin/bash

CODE_DIR="/data/engagement-dev/python/markup.mozilla.org/markup"
VENDOR_DIR="$CODE_DIR/ffdemo/vendor"
LOCALE_DIR="$CODE_DIR/ffdemo/locale"

echo -e "Updating code..."
cd $CODE_DIR
git fetch -q
git checkout origin/master -q
git submodule update --init -q ## <-- This is where it is trying to rmdir src/jingo

echo -e "Updating vendor..."
cd $VENDOR_DIR
git fetch -q
git checkout origin/master -q
git submodule update --init -q

cd $CODE_DIR/ffdemo
python26 ./manage.py migrate markup

cd $LOCALE_DIR
svn up

Comment 4

[Jeff Balogh (:jbalogh)]

Attachment: improved update script

I'm removing the fetch + checkout in $VENDOR_DIR and adding submodule sync.

Why:

There is a pointer in mozilla/markup to mozilla/markup-lib; submodules are essentially pointers to a repository + revision number.

mozilla/markup is currently pointing at revision eb4bb5b in markup-lib. You can see that at the bottom of https://github.com/mozilla/markup/tree/master/ffdemo, on the vendor directory.

The tip of mozilla/markup-lib is currently revision 9b6096ac13. That is what markup-lib:origin/master points at. That is one revision ahead according to https://github.com/mozilla/markup-lib/compare/eb4bb5b...9b6096ac13.

Since the script was doing fetch + checkout inside $VENDOR_DIR, the revision of markup-lib was getting ahead of what the submodule in mozilla/markup expected. The next time the script runs it tries to revert markup-lib from 9b6096ac1 to eb4bb5b. src/jingo was added in 9b609 so the reversion process tries to rmdir it.

Fixing the script will mean src/jingo is unavailable in markup-lib until the developers update the submodule pointer in mozilla/markup.

Comment 5

[Justin Dow [:jabba]]

I modified the script to match jbalogh's version. I don't see the rm error anymore.

Comment 6

[Austin King [:ozten]]

Bug#655805 is caused by jingo not being available.

Can we verify that src/jingo is visible to mod_wsgi for markup-dev?

Comment 7

[Justin Dow [:jabba]]

This was fixed by bumping the revision of markup-lib that gets used.