Regressão rasa de `git fetch` no discourse_docker

Suporte
1

Olá,

Um commit recente no docker_discourse quebra a capacidade de especificar uma tag (por exemplo, v2.6.0) no valor version: do app.yml. Isso é útil para instalar versões antigas do Discourse para fins de teste.

O problema se manifesta da seguinte forma ao especificar version: v2.6.0 ao usar e2eb085714dfcf2aa0117b0f2fdf39b762b0e18d:

I, [2020-12-05T10:59:38.848743 #1]  INFO -- : > cd /var/www/discourse && git remote set-branches origin v2.6.0
I, [2020-12-05T10:59:38.852600 #1]  INFO -- : 
I, [2020-12-05T10:59:38.852639 #1]  INFO -- : > cd /var/www/discourse && git fetch --depth 1 origin v2.6.0
From https://github.com/discourse/discourse
 * tag                 v2.6.0     -> FETCH_HEAD
I, [2020-12-05T10:59:41.405163 #1]  INFO -- : 
I, [2020-12-05T10:59:41.405307 #1]  INFO -- : > cd /var/www/discourse && git checkout v2.6.0
error: pathspec 'v2.6.0' did not match any file(s) known to git
I, [2020-12-05T10:59:41.411796 #1]  INFO -- :

Em vez da saída esperada ao usar o commit imediatamente anterior a esse.

I, [2020-12-05T11:22:14.717910 #1]  INFO -- : > cd /var/www/discourse && git fetch origin v2.6.0
From https://github.com/discourse/discourse
 * tag                     v2.6.0     -> FETCH_HEAD
I, [2020-12-05T11:22:15.672616 #1]  INFO -- : 
I, [2020-12-05T11:22:15.672683 #1]  INFO -- : > cd /var/www/discourse && git checkout v2.6.0
Note: checking out 'v2.6.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at d6121249d3 Version bump to v2.6.0
7 curtidas
3

Não chamaria isso de bug propriamente dito, mas queremos oferecer algum tipo de instrução sobre como instalar versões antigas do Discourse, mesmo que isso envolva um template mais complexo ou algo assim.

@Falco está investigando.

7 curtidas
4

Concordo que a profundidade deve ser configurável, talvez por meio de uma variável de ambiente, com o padrão sendo “shallow”; mas configurável com uma simples variável de ambiente.

1 curtida
5

Acho que o problema aqui é que as tags não são conhecidas localmente ao fazer o checkout, como no seguinte problema (não relacionado ao Discourse):

Executar git fetch --all deve resolver o problema, mas não sei o quanto isso poderia aumentar o tamanho da imagem (a menos que outra instrução limpe as referências não utilizadas mais tarde).

Dito isso, acho que git clone --depth 1 https://github.com/discourse/discourse.git --branch=$version resolveria, porque a opção branch permite tanto branches quanto tags, mas não testei e não sei se há algum motivo para o clone usar (atualmente) a branch master.

Ao executar git clone --depth 1 https://github.com/discourse/discourse.git --branch=v2.6.0, o tamanho total da pasta é de 212MB, e a pasta .git dentro dela tem 46MB, então acho que está tudo bem.

6

Isso duplica o tamanho do repositório :slightly_frowning_face:

O problema é que, no momento da construção da imagem, não sei qual branch você desejará no futuro.

A configuração atual foi alterada para reduzir o tamanho da imagem, o que diminuiu o tamanho comprimido em 250 MB (25%), uma grande vitória. Funciona bem ao usar branches normais, como stable e beta ou tests-passed.

Como solução alternativa, se você quiser mudar para uma tag, pode aplicar isso ao seu arquivo app.yml:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
+    - exec:
+        cd: $home
+        cmd:
+          - git fetch --depth=1 origin tag v2.5.0 --no-tags
+          - git checkout v2.5.0

Outra solução alternativa é adicionar uma chave base_image no nível superior do app.yml com o valor de uma imagem base mais antiga. Como nem sequer tentamos manter a compatibilidade das novas imagens para executar versões mais antigas do Discourse, isso pode ser necessário se você estiver voltando há bastante tempo.

9 curtidas
7

Você tem razão, naquele momento não sabemos a versão. Parece que a imagem base usa a versão atual + a branch tests-passed, embora a branch tenha o commit do momento em que a imagem foi construída.

A maneira como está sendo feita agora não resultaria em rebuilds mais lentos, mesmo quando a branch tests-passed é usada?

Basta considerar as seguintes instruções:

Na imagem base:

git clone --depth 1 https://github.com/discourse/discourse.git
cd discourse/
git remote set-branches --add origin tests-passed

Em web.template.yml

git reset --hard
git clean -f
git remote set-branches --add origin master
git pull
...
Quando `git pull` é chamado, **todo o repositório é baixado**, e pode levar vários minutos, pois apenas um clone superficial foi feito antes. Você pode tentar executar apenas as instruções acima localmente e ver. Não estou dizendo que ter todo o repositório na imagem base seja melhor, mas o código em `web.template.yml` será executado em cada rebuild, mesmo que apenas um plugin tenha sido adicionado ou uma configuração alterada em `app.yml`. O que normalmente faço em meus projetos (não Discourse) é criar uma nova imagem para cada nova versão, mas isso pode não ser viável para você (considerando como você faz atualmente). Você não percebeu algum aumento no tempo de rebuild? (ou talvez isso não seja tão grande comparado ao tempo total de rebuild na maioria dos casos)

Atualização

Testei as etapas acima novamente e foram rápidas. Acho que executei outra instrução na primeira tentativa que alterou a árvore do git e acabei tentando baixar tudo ao executar git pull.

2 curtidas
8

Você tem certeza disso?

➜  discoursesmall git:(6a42acbf) docker run --rm -it discourse/base:2.0.20201125-2246
root@b481d11669ba:/# cd /var/www/discourse/
root@b481d11669ba:/var/www/discourse# du -sh .                                                     
774M    . 
root@b481d11669ba:/var/www/discourse# git pull
...
root@b481d11669ba:/var/www/discourse# du -sh .                                                                
778M    .
5 curtidas
10

@lucasbasquerotto você está correto ao apontar que o git pull não é estritamente necessário; no entanto, removemos isso aqui

Isso deve permitir que outras branches (ou forks) funcionem de forma mais harmoniosa com o discourse_docker daqui para frente :slight_smile:

5 curtidas
11

Sim, vejo que ele faz um fetch e depois um checkout na branch correta após o pull, então acho que o git pull não é necessário (ainda não testei, porém).

Para as tags, parece que ainda preciso buscá-las separadamente, mas isso parece viável. Além disso, como as branches são mais comumente usadas, as tags devem ser mais um caso de borda.

1 curtida
12

É seguro assumir que a opção de versão no arquivo de configuração standalone.yml não tem efeito?

13

Ainda tem um efeito, mas agora só pode ser definido para branches.

3 curtidas
14

Estou recebendo o mesmo erro. Eu estava usando a versão 2.5.1.

Com isso, estou recebendo o seguinte erro:

I, [2020-12-31T11:50:24.701475 #1]  INFO -- : > cd /var/www/discourse && find /var/www/discourse ! -user discourse -exec chown discourse {} \+
chown: não é possível dereferenciar '/var/www/discourse/public/plugins/styleguide': Arquivo ou diretório não encontrado

A reconstrução não funcionará. alguma ajuda?

15

Tente adicionar a chave mencionada e usar uma imagem mais antiga em discourse/base - Docker Image

2 curtidas
16

Isso não funciona porque ocorre após o código que falha por não conseguir recuperar a versão. O que funcionou foi criar um arquivo version.template.yml ao lado do web.template.yml com o seguinte conteúdo:

params:
  home: /var/www/discourse

run:
  - exec:
      cd: $home
      hook: code
      cmd:
        - git fetch --tags

E, em seguida, incluir esse arquivo em containers/app.yml, antes do web.template.yml, da seguinte forma:

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/version.template.yml"
  - "templates/web.template.yml"
17

Para que isso funcione, você não deve usar a chave de nível superior version no seu app.yml, apenas esse novo código. Ao fazer isso, ele não falha.

3 curtidas
18

Obrigado por esclarecer: essa é exatamente a parte que me faltava. Para aqueles que estão confusos da mesma forma que eu, obter uma tag de release do Discourse pode ser feito da seguinte maneira:

  • Garantir que o parâmetro version não esteja definido no app.yml, por exemplo:
    params:
  db_default_text_search_config: "pg_catalog.english"
  #  version: stable
  • Adicionar código para fazer o checkout da versão desejada no final do app.yml, por exemplo:
    hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
+    - exec:
+        cd: $home
+        cmd:
+          - git fetch --depth=1 origin tag v2.5.0 --no-tags
+          - git checkout v2.5.0

Ao executar ./launcher rebuild app, o seguinte acontece:

  • A version padrão (ou seja, a branch test_passed) é verificada.
  • A tag v2.5.0 é buscada e verificada, substituindo efetivamente a versão anterior.
1 curtida
19

This topic was automatically closed 0 minutes after the last reply. New replies are no longer allowed.