Não há quatro pastas diferentes. Há dois nomes por data e current
é o mesmo que o mais antigo desses dois, e pending
é o mesmo que o mais recente desses dois.
Este parece ser o resultado da aplicação de alguns testes automatizados aos ISOs. De este blueprint :
Durante o ciclo quântico, houve momentos em que o ISO diário imagens tinham bug ou problemas neles, o que atingiu muitos usuários e ou testes automatizados de jenkins. Idealmente, queremos impedir que os usuários baixando imagens borked e reportando bugs repetidamente novamente. Devemos discutir e possivelmente implementar algo para ajudar com isto, por exemplo:
- considere o upload de imagens para uma área de teste, executando o teste de Jenkins e se os testes de jenkin passarem, em seguida, publique as imagens iso
- ou, por exemplo, enviar notas de falha de teste de jenkin para o cdimage / iso-tracker (como o aviso de tamanho grande)
- pense em possivelmente extrair imagens borked de cdimage.u.c
- comunica "por que ainda não havia uma compilação diária?" enviando a notificação "FTBFS" para o iso-tracker & amp; cdimage.u.c
- comunica o processo respina de forma mais automática, por ex. no rastreador iso / cdimage.u.c
Objetivo:
- Tente executar alguns testes automatizados antes de as imagens serem publicadas
- Trabalhe com a equipe de testes do Unity para garantir que a unidade funcione (faça com que os jenkins unitários fiquem em dowstream do teste de jenkins padrão do desktop)
pending
é essa área temporária, como pode ser visto nas notas mais abaixo na página de blueprint.
Por que ter um conjunto de pastas com base em datas e outro conjunto com nomes, é mais fácil:
- para que o script tenha pastas como
current
, que sempre apontam para a versão atual, - para atualizar atomicamente as pastas se
current
epending
forem links simbólicos para pastas que contêm os ISOs reais.