Re: Running patchy (merge staging)

[Graham Percival]

On Wed, Feb 01, 2012 at 11:55:24AM -0000, Phil Holmes wrote:
> My draft instructions, based on my memory of what I did.

Looks good!  Here's a few little notes, including the reason why I
couldn't test David's 2040 patch.
(coincidently, I'm waiting for my supervisor to show up, so I
spent 10 minutes looking into it just now)

> 1. Create a new user on your box - use this solely to run patchy.
> On my system it has admin privileges but I don't know if that's
> necessary.  New users are created from System; Administration; Users
> and Groups.

I recommend *not* giving the user admin privileges.  The main
reason to do this in a separate user is in case somebody sneaks a
rm -rf into the build system -- that's not really a worry for
staging (because we trust people with git push ability), but
there's absolutely no checks for a Patch-new.  Might as well get
into the habit of good security now, so nobody is unpleasantly
surprised if they use their merge-staging setup for test-patches
and encounters a problem.

(yes, the user should still be required to type in his password
before he can do anything truly bad, but it's still good practice
to give the minimum amount of privileges required when blindly
running code that anybody on the internet can submit)


Also, the big explanation for David:
- I was always doing "su lily" to switch to my patchy user, so it
  would only occupy one terminal and I could use my computer for
  other stuff
- I forgot that bash reads different files depending on whether
  it's an interactive shell vs. a new login vs. whatever.
  (this is that ~/.profile vs. ~/.bash_profile vs. ~/.bashrc
  nonsense)
- when you do "su username", apparently bash DOESN'T change your
  environment variables.
- therefore, my lily user has $LILYPOND_GIT pointing to
    /home/gperciva/src/lilypond/
  and since I very rarely touch that directory any more, I wasn't
  doing any git pull or git fetch there.

Moral of the story: once you have a separate user set up,
double-check that everything is actually happening for that
separate user.  and/or we might even give explicit instructions on
what to put into your ~/. files.

> 2. Get the patchy scripts from
> https://github.com/gperciva/lilypond-extra/ patches
> 
> 3. Put the scripts in a sensible place on your system

I just run them from the git repo; that allows for easy updating.
Alternatively, one could set up symlinks.

> 6. Edit lilypond-patchy-config-DEFAULT to provide working
> directories for your build directory, your results directory,
> compiler options and notification method.  If you don't want to use
> email notification, then delete everything after smtp_command:.
> Save this without the -DEFAULT.

-1
Don't change the -DEFAULT; instead, change
~/.lilypond-patchy-config after the -DEFAULT has been copied to
that location.

> 7. Ensure that your new user has git push access.  Follow the
> instructions in the CG. 
> http://lilypond.org/doc/v2.15/Documentation/contributor/commit-access.
> I have not set password protection for the key - I assume that if I
> did I could not run patchy unattended.

+1

> 8. python lilypond-patchy-staging.py.  Not much happens except a lot
> of CPU gets used...  Please let me know if you plan to do this - I
> won't run patchy myself.  There's not much point trying it unless
> there something in staging to be merged to master.

+1

> 9. Results are in a log*.txt file in the directory given by
> auto_compile_results_dir.

Yes.  Note that if you have email set up, you'll get those logs
via email.

Once somebody with a powerful, always-on computer sets this up,
I'd suggest a
  10. add this to your cronjob
so that nobody needs to think about it.

Cheers,
- Graham