automatizar criação de binários (instalação, ferramenta standalone, shelltests) about jfstmerge HOT 20 CLOSED

@jvcoutinho na realidade é mais interessante mantermos esses binários num repositório à parte. Toda vez que commitamos os binários recebemos a seguite mensagem:

remote: warning: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: warning: See http://git.io/iEPt8g for more information.
remote: warning: File installer/s3mInstaller.jar is 75.25 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB

Sem contar que deixa o projeto muito grande para só quem precisa do código fonte. Então, idealmente, o que precisamos é o seguinte.

1. Mecanismo de geração automática de binários (o instalador e a ferramenta standlone).
2. Armazenamento em umrrepositório secundário desses binários
3. Apagar esses binários do repositório oficial
4. Geração automática do binário para a execução dos shelltests. @gaabs já faz isso em #34 precisamos sincronizar isso

ok @pauloborba ?

from jfstmerge.

@guilhermejccavalcanti se esse arquivo só é modificado de tempos em tempos, poderia deixar tudo no mesmo repositório mesmo, para eliminar um ponto de falha e simplificar a replicação. se é modificado frequentemente, aí faz mais sentido deixar em outro local mesmo

from jfstmerge.

from jfstmerge.

from jfstmerge.

@guilhermejccavalcanti @pauloborba eu posso adaptar a configuração do Gradle para copiar os binários para suas devidas pastas, ok? E sobre o repositório secundário, ele conterá sempre o último binário modificado, "espelhando" o código do repositório principal, é isso?

from jfstmerge.

eu posso adaptar a configuração do Gradle para copiar os binários para suas devidas pastas, ok?

como seria isso na prática? em que momento haveria essa criação e copia dos arquivos? Se liga também que o s3mInstaller.jar contém um s3m.jar (uma versão renomeado do jFSTMerge.jar). Então teria que abrir esse s3mInstaller.jar, e substituir o jar de dentro pelo novo, toda vez.

E sobre o repositório secundário, ele conterá sempre o último binário modificado, "espelhando" o código do repositório principal, é isso?

isso, e o readme original tirando a parte referente a código.

from jfstmerge.

from jfstmerge.

Entendi, ainda assim, não seria 100% automático, né, pois temos que nos lembrar de gerar a build do gradle pra pegar os jars? @gaabs fez algo automático no momento de execução do travis, num foi?

from jfstmerge.

from jfstmerge.

Não, não. Não tenho preferência não. O que tou querendo saber se há como deixar isso totalmente automático, pois a build do gradle é manual, ou tou errado?

from jfstmerge.

from jfstmerge.

Para usar o novo recurso, basta digitar
git lfs install --skip-smudge
na linha de comando. Esse parâmetro fará o git lfs não fazer download nos binários.

from jfstmerge.

@jvcoutinho onde informacoes como essa acima aparecem no readme/codigo para ajudar a quem quiser colaborar com o desenvolvimento do sistema? é importante documentar bem para reduzir a barreira de colaboracao com o projeto

from jfstmerge.

@pauloborba posso atualizar o README com as mudanças feitas até agora, pode ser?

from jfstmerge.

sim, por favor

from jfstmerge.

Tem um bug com essa abordagem, que eu não previ. Como o updateInstaller apenas modifica um arquivo dentro do jar, caso este só seja uma referência pro arquivo original, não há como modificar.

from jfstmerge.

@jvcoutinho mas temos efetivamente uma situação dessa, de querer atualizar um arquivo que é um alias para outro arquivo?

from jfstmerge.

Sim, isso é visível nos repositórios locais.
Uma abordagem mais certeira é gerar o binário do 0, ao invés de atualizar apenas um arquivo dentro.

from jfstmerge.

@guilhermejccavalcanti and @gaabs any opinion on that?

from jfstmerge.

@phmb Eu pensei em outra abordagem, que foi baixar o jar do instalador antes de fazer o update. O comando git lfs pull faz isso, e é rápido.
Isso vai criar uma dependência do gradle com o git lfs, mas é melhor do que criar o arquivo do 0, na minha opinião.

from jfstmerge.