Usando Hudson e etapas de construção com múltiplos repositórios git

Question

Eu estou tentando sair Hudson para substituir a nossa configuração Buildbot atual. Eu instalei o plugin git. Nossa configuração atual é semelhante:

ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git

Agora, para construir project_a eu adicionei um novo trabalho com múltiplos repositórios git (aqueles acima). Eu queria Hudson para clonar os repositórios em diferentes diretórios sob $WORKSPACE, becase necessidades test_framework que a hierarquia. Mas Hudson parece fundir tudo em $WORKSPACE vez. Do registro de console:

warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0

Posso configurar esta em Hudson para atender melhor a nossa configuração do projeto? Eu preciso criar um repositório git manequim local com cada projeto como submódulos git ou algo assim?

Answer 1

Dentro de Hudson que você pode encadear vários trabalhos juntos. Você poderia tentar criar empregos Hudson separados para test_framework e outro para project_a. Hudson cria um diretório separado em $ espaço de trabalho para cada trabalho, então agora você deve ter duas pastas diferentes sob $ espaço de trabalho.

---

Configuração encadeamento

Na configuração trabalho project_a desloque-se para ações pós-compilação e de seleção criar outros projetos ... Digite na test_framework como o projeto de construção.

Na configuração trabalho test_framework garantir que Poll SCM é desmarcada e que constroem depois de outros projetos está definido para project_a.

---

Como funciona

O que você tem agora configurado é project_a vai sondar o SCM procura de mudanças, quando as alterações são encontrados ele vai puxar-los de git. Executar etapas de construção (se houver) e no gatilho conclusão do trabalho test_framework às mudanças puxar de git (se houver) e executar suas etapas de construção.

Answer 2

O problema com a solução "Construir outros projectos" é que se houver alterações para test_framework ela não será desencadeada project_a para construir. Em vez disso, eu recomendo abandonar o plugin git ea criação de um passo de compilação "Executar shell" com o seguinte:

rm -rf ${WORKSPACE}/*

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

Em seguida, criar arquivos gancho "servidor: /repo/test_framework.git/hooks/post-receive" e "servidor: /repo/project_a.git/hooks/post-receive" com o seguinte conteúdo:

#!/bin/sh
curl http://hudson/job/job_name/build

Agora, sempre que alterações são empurrados para qualquer repositório, o gancho vai usar a API do Hudson para desencadear uma compilação.

Answer 3

Eu percebo esta pergunta é muito antiga, mas eu corri para o mesmo problema e usou esta página para aperfeiçoar a minha própria solução que parece estar funcionando muito bem (mesmo que seja um pouco complicado). A maior parte do crédito por esta solução deve ir para Clinton (a única razão pela qual eu estou incomodando submeter esta resposta é porque a resposta não parece endereço de múltiplos repositórios que precisam ser no mesmo diretório base).

Suponha que você tem dois repositórios (A e B).

Passos:

1) Faça dois projetos para código de puxar a partir de repositórios remotos A e B. Coloque quaisquer etapas de construção necessários em qualquer repositório.

2) Faça uma terceira diretório sem qualquer gerenciamento de controle de origem. Adicionar uma etapa de compilação para esse projeto para executar um comando shell semelhante a esta:

ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B

(seus caminhos podem não ser o mesmo. Procurá-los você mesmo!)

Agora você pode adicionar quaisquer outras etapas de construção que dependem sendo irmãs A e B em um diretório. Yay links simbólicos!

3) Cadeia as três tarefas juntos. A ordem das tarefas de puxar pode ou não importa (você sabe melhor do que eu), mas a tarefa sem controle de origem deve ser o último elo da cadeia.

Answer 4

Eu corri para o mesmo problema e atualmente resolvido através da criação de um emprego para cada projeto e usando o Copiar Artefato Plugin para permitir a construção do trabalho dependente mesmo que uma atualização Git é feito em suas dependências (isto é para evitar a construção no meio de uma atualização para o projeto que depender) .

Assim project_a iria copiar as últimas artefatos estáveis ??que necessita de test_framework e uma atualização para o framework de teste provocaria uma construção em project_a. project_a ainda pode ser desencadeada por uma mudança no Git, ele apenas copia novamente os mais recentes artefatos em test_framework.

Answer 5

O problema que você está descrevendo já está arquivado como bug no bugtracker Jenkins: https: / /issues.jenkins-ci.org/browse/JENKINS-8082

---

Nós usamos a opção "área de trabalho personalizada" na configuração do trabalho de projeto estendida para finalizar compra repositório do nosso trabalho em um subdiretório de outro emprego.

Que outras verificações de emprego fora do diretório principal com todos os sub-módulos:

var/lib/jenkins/jobs/
  + main_job
    + workspace (main git checkout with submodules)
      + modules
        + mod1
        + mod2
  + mod1_job (custom workspace set to main_job/workspace/modules/mod1)
    + workspace (empty)