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.

Ok.

>> 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.

Yes, we just remove 4c or 5, thanks.

>> 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.)

And if commit produce conflict(s) on merging to mainline archive, then 
1) commit on developer archive are success;
2) commit on mainline (pqm's) archive are fail;
3) developer receive e-mail from pqm about fail in point 2.;
4) developer do `tla star-merge ...' for sync up with mainline project tree;
   and manually handle all conflicts;
5) developer do commit again.

I am understood right?

>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.

E-mails will be sending by pqm to addresses from `tla my-id' of developers, 
true?

>> 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.

And if maintainer want to create new version, his just
1) tell to developers for they commit changes;
1) make new version (tla tag) in mainline archive;
2) notify all developers about that;
Developers need to `tla get mainline-archive/project--devo--new-version'
and next changes they must do in new version tree.

True?

>> 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.

We think what new version's make - not often operation, and manual creating 
email for notify developers - right choice for us.

>> 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.

We think maintainer in own schema will differ from developers only in next 
points:
1) Only maintainer will have access to pqm user account (and to mainline 
archive);
2) Only maintainer will have responsibility about making new versions ;)

>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".

Thank!

>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.

Pqm is fine for us!

>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.

Yes, you right. We will trust own developers.

>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.

Thanks for links. So pqm method is more likely for us:
1) No need to dance with umask and access rights;
2) Centralized pre-commit and post-commit hooks, which called _every_time_
   mainline archive changed;

--------------------------------------------------------------------------
Robert Collins wrote about arch-pqm:
>Its the same one, just a more recent version - adding support for acls
>on a per branch basis, baz, various bugfixes, a replay command.
>Http://people.ubuntu.com/~robertc/address@hidden/arch-pqm-->main--0

Right link:
http://people.ubuntu.com/~robertc/address@hidden/arch-pqm/arch-pqm--main/arch-pqm--main--0/

Big thanks. Robert, is this you fork from official arch-pqm project?

WBR, Alexander Popkov.