Re: [Gnu-arch-users] ARCH usage schema for automated updates live files after maintainer commits

[John Arbash Meinel]

Попков Александр wrote:

> Hello GNU ARCH users!
>
> Advice me please better ARCH usage schema for next situation:
>
> 1. One development server with one-per-developer account;
>
> 2. One live (production) server with running services;
>
> 3. Source files in project – are PERL files and binary build are not
> needed;
>
> 4. Each developer must have possibility to:
>
> 4a. Edit project files;
>
> 4b. Commit own changes (from self-owned archive?) to main arch archive;
>
> 4c. Do some actions for update project files on live server
>
> to latest version of project from main arch archive on development server;
I actually think that you *don't* want this (4c). If you get rid of this
requirement, it simplifies the rest of your work.
Make it so the maintainer is the only person with login access to the
live server.

> 5. Developers (but maintainer) must NOT have direct access to project
> files on live server,
>
> for maintainer be sure what all project’s changes are logged in changelog;
Again, look at my above comment. 4c conflicts with 5. Hence I recommend
removing 4c. Unless I just misunderstand what you were arguing for.

> 6. After (before?) all changes (commits) to main arch archive system
> must run some test
>
> associated with particular project. If test fails – rollback or cancel
> commit.
This can be done with arch precommit hooks. The difficulty here, is that
arch is a client only process. So you have to setup *every* developer
with the precommit hooks. It is a simple fact of the arch design.
There is an alternative, though. Using a patch-queue-manager (pqm).
http://web.verbum.org/arch-pqm/
I believe there is another one in use by the baz folks, but they'll have
to mention that one.

Basically, you have an automated script (the pqm), which handles
committing to the main archive. Developers commit to a different archive
(possibly just their personal one), and then inform the pqm that there
is pending work to be merged into the mainline. (This can probably be
done in a post-commit hook if you want to make it easier on the developers.)

This pqm is then instructed to do a test merge, verify that the merge
passes the tests, before committing to the main archive. At this time,
the pqm can also handle all of the emails that you want to send. Or if
it fails, the pqm can email the developer letting them know what went wrong.

> 7. After each commit to main arch archive system must send e-mail to
> maintainer;
>
> 8. Only maintainer must have rights for making new
> category/branch/version in main arch archive;
Again, the pqm provides a barrier between the developers and the main
archive, so if only the pqm and the maintainer have access, and the pqm
doesn't have any rules for creating a new category/branch/version, then
there shouldn't be any problems.

> 9. After maintainer make new version of particular project system must
> send e-mail to all project developers;
>
> (and developers go to update own local copies of changed project?);
Some of this can most easily be done by self-discipline of the
maintainer. It can also be done with a post-commit hook. I'm not sure if
there is a post-tag or post-branch hook, but you could work something
like that out.

> 10. Updating project files on live server process must have two cases:
>
> 10a. Update files in “TEST” location, for manual testing on LIVE server.
>
> 10b. Update files in “HOT” (production) location on LIVE server.
Is this being done by the maintainer or by developers? Because in 5 you
stated that devs can't touch the live server.
It really only amounts to having 2 locations "checked out". The
maintainer runs "tla update" in the test location, tests the system on
the live server, then can cd over to the production location and do
another "tla update".

> Thanks in advance!
Good luck. Hopefully people who are actively using a pqm will speak up.
As I think it really fits what you are wanting to do. If you don't want
to go through that work, we have also worked out some other alternatives.

The first key is do you trust your developers to not try and subvert the
system. If so, that simplifies a lot of things.
One of the problems with having tests run automatically, is that you are
allowing the developers to cause arbitrary code to be run on some other
machine. You probably can trust your developers, I just want to bring up
the fact that if you are running automatic tests, there is nothing to
stop the developers from submitting the "test" which runs an arbitrary
command.

If you don't want the pqm, you can read about hook scripts here:
http://wiki.gnuarch.org/Using_20hooks

You can use JohannesBerg's method (near the end) which lets you run a
per-package hook script. By tying into the precommit hook, you can have
tests run, etc.
If you want to prevent creation of new cat/branch/version, you can make
all directories non-group writable (chmod go-w), except for the final
directory where the new revisions are created. You'll also want to check out
http://wiki.gnuarch.org/Centralized_20Development
To see how to have multiple people committing to the same archive.

John
=:->

signature.asc
Description: OpenPGP digital signature