Hudson

O site java.net foi alvo de um ataque DDos hoje, conforme twitpost do hudson:

Apologies for those of you seeing more Java.net issues, Java.net is experiencing a DDoS attack right now; drastic measures are being taken.

E quando isto ocorreu, verifiquei que o meu ambiente hudson ficou instável, tentando conectar ao hudson.dev.java.net e todo custo, e ainda, não estava gerando as tasks que continham parâmetros ( parametrized builds), pois bem, abri o bug 4590, no hudson e me foi informado que poderia colocar um prâmetro na jvm ao iniciar o hudson, que desabilita a visita ao site para verificar atualizações, inclusive deixando até levemente mais ágil meu ambiente…

Gostei! o parâmetro é: -Dhudson.model.UpdateCenter.never=true

Feito isto, reinicie seu serviço do hudson, e continue seu trabalho !

Link de apoio: http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson

Related posts:

1. Hudson, acompanhando os builds…
2. Shell Script + Hudson
3. Hudson – Projeto Pai/Filho

Eu aguardava anciosamente este plugin…

http://wiki.hudson-ci.org/display/HUDSON/Python+Plugin

Com ele, é possivel executar scripts python como passos de um build.

Assim como já é possível com BASH, BAT, ANT, Groove, Grails, Maven, Ruby, entre outras mais…

De repente fica fácil até integrar o Hudson , com Python e Distutils ou EasyInstall ( ferramentas estas que ainda estarei estudando mais para frente… ), gerando assim um ótimo ambiente de compilação e geração de builds e entregáveis.

Vamos ver no que vai dar…

Comente sobre o EasyInstall e Distutils, e fale o que acha de melhor em cada uma …

Related posts:

1. Finalmente….
2. Finalmente……
3. Shell Script + Hudson

É muito fácil programar em Shell Script.
Agora que realmente precisei desta feature para incrementar os builds do Hudson, aqui no ambiente do trabalho, acabei gostando mesmo.
E com uma fonte de pesquisa muito 10 chamada CANIVETE ( http://aurelio.net/shell/canivete.html ) , do Aurélio, que me ajuda em tudo, ficou mais fácil ainda.

Achei também um tutorial de “Introdução ao Shell Script”, advinha de quem? Aurélio, que me ajudou muito nos passos iniciais e a entender alguns pontos ainda obscuros para mim.

No Hudson, temos como chamar scripts de Shell Script, e estes recebem os parametros do projeto atual, por exemplo:
Tenho um projeto chamado XYZ, este projeto tem como workspace ‘/home/hudson/workspaces/xyz’ e tem um parametro chamado ‘nome’.
Crio um .sh , e mando o projeto executar, clicando em “Add build step->Execute Shell”, informando o caminho para o shell, por exemplo ‘/home/hudson/scripts/meushell.sh’. Ok !

Neste shell, eu tenho disponível uma gama de variáveis de ambiente, disponibilizadas pelo Hudson, como:

$WORKSPACE = Informa o diretorio da workspace do projeto
$BUILD_NUMBER = Numero do build corrente
$BUILD_ID = Id completo , identificador, do build.
$JOB_NAME = Nome do projeto
$JAVA_HOME = Caminho do java que está sendo executado pelo hudson

E por ai vai …

E mais as variáveis que foram definidas como parametros, quando mandamos o projeto construir, será solicitado um valor para cada paremtro definido, e estes valores chegam em forma de variáveis de ambiente em nosso script, como $NOME, no nosso exemplo supra citado.
O script será executado pelo ‘/bin/sh’ passando -xe como parametro, para que seja mostrado cada comando exetudado pelo shell, ou se você configurar um executor shell direfente, este será respeitado (Hudson->Gerenciar Hudson->Configure System->Shell) .

Aliás, eu gosto de fazer uma estrutura simples de diretorios para trabalhar com cada projeto no Hudson, que seria mais ou menos assim:

HOME:/home/hudson
Logs do hudson: $HOME/logs
Scripts ( sejam eles ant, shell, bat, groovy, etc… ) $HOME/scripts
Locais de Trabalho (workspaces) : $HOME/workspaces/[NOME PROJETO]
Local para atualização de códigos do SVN/CVS: $HOME/workspaces/[NOME PROJETO]/SVN
Local para deposito de artefatos gerados ( somente finais ): $HOME/workspaces/[NOME PROJETO]/BUILD
Local para trabalho de scripts dentro de cada projeto ( arquivos temporarios, alterados, movidos. etc… ) : $HOME/workspaces/[NOME PROJETO]/WORK

/home/hudson
/home/hudson/logs
/home/hudson/scripts
/home/hudson/workspaces
/home/hudson/workspaces/[NOME DO PROJETO]
/home/hudson/workspaces/[NOME DO PROJETO]/SVN
/home/hudson/workspaces/[NOME DO PROJETO]/BUILD
/home/hudson/workspaces/[NOME DO PROJETO]/WORK

Assim, mantemos um padrão para todos os projetos, facilita, e muito, a geração de scripts para os builds.

Fica aqui ume pequeniníssima contribuição de um shell, que limpa arquivos .mine, que as vezes são gerados pelo subversion:

#!/bin/sh
echo Verificando arquivos .mine no caminho: `pwd`
for f in `find . -name *.mine` 
do
    echo Removendo mines de: ${f%.mine}
    rm -rf ${f%.mine}* 
done

Related posts:

1. Hudson – Projeto Pai/Filho
2. Hudson, acompanhando os builds…
3. Ajuda dos Deuses…

Tem algumas maneiras de fazer isto:

1º RSS : simples, normal, como conhecemos… qq leitor comum de feed pode fazer este trabalho.
Link: http://seuservidor:8080/rssAll ou http://seuservidor:8080/rssFailed ou http://seuservidor:8080/rssLatest

2º Hudson Tracker: um ícone ficará no seu systray mostrando o andamento dos builds, e pipocando uns pequenos  balões de aviso …
Link: http://wiki.hudson-ci.org/display/HUDSON/hudsonTracker

3º Hudson Status Monitor : Simples página, que mostra o status de todos os projetos e se estão sendo criados neste momento ou não.
Link:

Com estas 3 opções podemos manternos informados, em qq lugar, sobre os builds dos nossos projetos.

Related posts:

1. Hudson – Projeto Pai/Filho

Na real, não sei se á a resolução correta para este caso, mas o caso é que coloquei o ANT_HOME/bin no path do SO e reiniciei o Hudson, e depois de trocar algumas configs nos projetos e salvá-los tb, tudo funcionou. Agora um projeto pai chama o filho normalmente.

Legal !

Related posts:

1. O bom filho a casa torna …
2. Filho pródigo….