Então, estamos usando o Gerrit Trigger (2.21.1) em nosso gerenciador de criação e & usando contêineres docker para as compilações reais.
O problema que surgiu recentemente em algumas de nossas filiais, o polling do Gerrit Repo está falhando e fazendo com que ele "detecte mudanças" todas as vezes, por isso está constantemente sendo reconstruído, apesar de nenhuma alteração.
A verificação do registro de sondagem Repet Gerrit para qualquer um dos trabalhos afetados fornece uma de duas saídas:
Gerrit Repo Polling Log
Started on Dec 20, 2016 11:31:01 AM
Que nunca parece preencher ou:
Started on Dec 20, 2016 12:27:01 PM
Polling SCM changes on aosp-host
[workspace] $ repo init -u http://xxx.xxx.xxx.xxx/git/project/platform/manifest.git -b branch -m branch.xml
Get https://gerrit.googlesource.com/git-repo/clone.bundle
Get https://gerrit.googlesource.com/git-repo
fatal: Not a git repository: '/home/jenkins/workspace/.repo/manifests.git'
fatal: Not a git repository: '/home/jenkins/workspace/.repo/manifests.git'
fatal: cannot obtain manifest http://xxx.xxx.xxx.xxx/git/project/platform/manifest.git
Done. Took 1 min 19 sec
Changes found
As construções, que são acionadas por essa falha, usam os mesmos comandos e funcionam bem:
[workspace] $ repo init -u http://xxx.xxx.xxx.xxx/git/project/platform/manifest.git -b branch -m branch.xml
Navegando até o diretório do manifesto, vemos o sintoma:
jenkins@f052b3453d95:~/workspace/.repo$ ll
total 32
drwxr-xr-x 1 jenkins jenkins 180 Dec 20 11:08 ./
drwxrwxr-x 1 jenkins jenkins 778 Dec 20 11:07 ../
-rw-r--r-- 1 jenkins jenkins 20087 Dec 20 10:14 .repo_fetchtimes.json
lrwxrwxrwx 1 jenkins jenkins 20 Dec 20 10:13 manifest.xml -> manifests/company.xml
drwxr-xr-x 1 jenkins jenkins 8 Dec 16 17:33 manifests/
drwxr-xr-x 1 jenkins jenkins 50 Dec 16 17:33 manifests.git/
drwxr-xr-x 1 jenkins jenkins 28 Dec 16 17:43 project-objects/
-rw-r--r-- 1 jenkins jenkins 7756 Dec 20 10:14 project.list
drwxr-xr-x 1 jenkins jenkins 410 Dec 16 17:46 projects/
com
lrwxrwxrwx 1 jenkins jenkins 20 Dec 20 10:13 manifest.xml -> manifests/company.xml
destacado em vermelho, porque o company.xml associado não foi encontrado ... portanto, o Gerrit Log acima está correto, não está funcionando corretamente em init . Isso é confirmado por meio de um repo status no diretório principal:
jenkins@f052b3453d95:~/workspace$ repo status
Traceback (most recent call last):
File "/home/jenkins/workspace/.repo/repo/main.py", line 531, in <module>
_Main(sys.argv[1:])
File "/home/jenkins/workspace/.repo/repo/main.py", line 507, in _Main
result = repo._Run(argv) or 0
File "/home/jenkins/workspace/.repo/repo/main.py", line 180, in _Run
result = cmd.Execute(copts, cargs)
File "/home/jenkins/workspace/.repo/repo/subcmds/status.py", line 130, in Execute
all_projects = self.GetProjects(args)
File "/home/jenkins/workspace/.repo/repo/command.py", line 140, in GetProjects
all_projects_list = manifest.projects
File "/home/jenkins/workspace/.repo/repo/manifest_xml.py", line 350, in projects
self._Load()
File "/home/jenkins/workspace/.repo/repo/manifest_xml.py", line 407, in _Load
self.manifestProject.worktree))
File "/home/jenkins/workspace/.repo/repo/manifest_xml.py", line 443, in _ParseManifestXml
root = xml.dom.minidom.parse(path)
File "/usr/lib/python2.7/xml/dom/minidom.py", line 1918, in parse
return expatbuilder.parse(file)
File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 922, in parse
fp = open(file, 'rb')
IOError: [Errno 2] No such file or directory: '/home/jenkins/workspace/.repo/manifest.xml'
O problema é que executar repo init -u <url> -m company.xml pela linha de comando funciona bem e produz um repositório válido.
Qualquer insight que alguém possa oferecer sobre esse problema?