Estou com um problema chato que não consigo resolver.
O que estou tentando fazer?
post-review --repository-url=http://xxx.xxx.xxx.xxx/svn/testRepo2 --revision-range=6:7 --server=http://reviews.example.test/ --username=reviewposter --password=mydullpass --submit-as=admin -p --target-groups=reviewers
Está tudo bem quando tento fazer isso no bash logado como meu usuário. A revisão foi postada, publicada, etc. ==> Todas as permissões e outras configurações diversas estão OK.
O que acontece quando tento fazer isso no gancho pós-commit do SVN?
Os recursos são confirmados, mas a operação svn trava - na verdade, o gancho pós-confirmação não termina.
A que se resume o problema?
post-review é executado como o usuário que está executando o gancho pós-commit - neste caso, o usuário www-data do Apache. Ou seja, quando executo o comando como www-data:
sudo -u www-data post-review --repository-url=http://xxx.xxx.xxx.xxx/svn/testRepo2 --revision-range=6:7 --server=http://reviews.example.test/ --username=reviewposter --password=mydullpass! --submit-as=admin -p --target-groups=reviewers -d
Eu recebo (observe o parâmetro -d no comando pós-revisão - DEBUG):
RBTools 0.4.1
Home = /home/borislav
Password for 'www-data':
É aqui que ele fica esperando a digitação de uma senha. A operação de commit não pode terminar e simplesmente permanece lá. Eu já discuti isso com os caras doGrupo do Google do ReviewBoard nesta postagem.
Por outro lado, quando executo o mesmo comando com saída de depuração, mas como myuser recebo:
RBTools 0.4.1
Home = /home/borislav
HTTP GETting api/
HTTP GETting http://reviews.example.test/api/info/
Using the new web API
TTP GETting http://reviews.example.test/api/repositories/
HTTP GETting http://reviews.example.test/api/repositories/1/
HTTP GETting http://reviews.example.test/api/repositories/1/info/
HTTP GETting http://reviews.example.test/api/repositories/2/
HTTP GETting http://reviews.example.test/api/repositories/2/info/
HTTP GETting http://reviews.example.test/api/repositories/3/
HTTP GETting http://reviews.example.test/api/repositories/3/info/
HTTP GETting http://reviews.example.test/api/repositories/4/
HTTP GETting http://reviews.example.test/api/repositories/4/info/
Attempting to create review request on http://xxx.xxx.xxx.xxx/svn/testRepo2 for None
Submitting the review request as admin
HTTP POSTing to http://reviews.example.test/api/review-requests/: {'submit_as': 'admin', 'repository': 'http://xxx.xxx.xxx.xxx/svn/testRepo2'}
Review request created
Attempting to set field 'target_groups' to 'reviewers' for review request '22'
HTTP PUTting to http://reviews.example.test/api/review-requests/22/draft/: {'target_groups': 'reviewers'}
Uploading diff, size: 2316
HTTP POSTing to http://reviews.example.test/api/review-requests/22/diffs/: {'basedir': '/'}
Publishing
HTTP PUTting to http://reviews.example.test/api/review-requests/22/draft/: {'public': 1}
Review request #22 posted.
http://reviews.example.test/r/22/
Então, na verdade, tudo com postagem/publicação etc.
Um dos desenvolvedores do ReveiwBoard afirmou que"Não exibimos a string" Senha para '' ". Então, isso vem de algo totalmente diferente."
Tenho certeza de que é algum tipo de permissão de execução. Deve rodar no Ubuntu Server, então pense no Debian.
Eu queria saber se ele tinha alguma conexão com o paradigma "sem login root" no Ubuntu.
Não experimentei outra distribuição Linux, o que não é realmente uma opção, já que o servidor SVN está hospedado no Ubuntu Server.
Você pode checaressa discussão que eu tivecom o pessoal do grupo de óculos do ReviewBoard. Opós-revisãobinário está localizado em:/usr/local/bin/post-review
Eu tentei adicionar permissões parawww-dadospara poder executarpós-revisãono arquivo sudoers, mas sem sorte.
Em que solução você consegue pensar?
Agradecemos antecipadamente, Borislav.
Responder1
O prompt de senha vem, na verdade, do svn, não da pós-revisão. post-review chama o binário svn para recuperar as alterações do repositório.
Você não vê o prompt de senha como seu usuário porque já se autenticou e o svn armazenou suas informações de autenticação. Você ainda não fez isso como usuário www-data, então o svn pede a senha.
A maneira mais fácil de corrigir isso seria su como usuário www-data e autenticar no repositório, para que as credenciais sejam armazenadas em cache.