@gmgall cheira a problema de CORS (o webserver local não tem esses problemas porque tudo vem dele) - vale dar uma olhada no console pra ver se esses resources não estão vindo de um protocolo/domínio diferente do que serve a página (e se for o caso de serem diferentes, se é possível encaixar meta-tags de headers para o browser relaxar um pouco).

@chesterbr Realmente esqueci de checar, mas quando é CORS o console mostra como tal, não?

Aqui só aparece 404 mesmo.

@gmgall é, se fosse o caso teria mensagens assim no console. Vale a pena botar na aba network do Development Tools do navegador e dar um reload (não apenas pra ter "110%" de certeza que não é CORS, mas porque de repente surge alguma info nos requests individualizados)

@gmgall se o projeto for público, vale a pena botar a URL, de repente a galera acha a treta (ou descobre coisas interessantes, por ex., se funciona para outras pessoas e não pra você)

@chesterbr Nossa, cara. foi incrivelmente aleatório.🤦

Já uso GitHub Pages faz um tempo e nunca tinha esbarrado com esse comportamento.

Consegui fazer uma das páginas da documentação renderizar certinho.

Renomeei o diretório em que estavam os arquivos CSS/JS/etc. (e acertar o nome do arquivo nas tags link, a, etc.)

O problema era um underline.

O arquivo é servido se no path não tiver um underline. O Sphinx gera vários diretórios cujo nome inicia com underline.🤦

@chesterbr O servidor local que eu subia para testar servia os arquivos independente do nome, então localmente funcionava.

@gmgall Interessante! Não trabalho mais no GitHub (e mexi bem pouco com Pages lá), mas não consigo imaginar nada que impedisse um path com underline de ser servido. Fosse, sei lá, um ponto na frente, eu até entenderia... 🤔

@gmgall hmm, agora me veio algo à cabeça: o Jekyll usa o prefixo "_" para indicar páginas que *não* devem ser publicadas (posts, templates, etc); me pergunto se o processo de publicação lá não tem algo que evita a exibição dessas páginas (o que faria todo o sentido quando Jekyll era o único engine possível, mas agora que você pode trazer o seu próprio com Actions, nem tanto)...

@gmgall E de fato, é o comportamento padrão - mas tem como dar override, cf: https://github.blog/2009-12-29-bypassing-jekyll-on-github-pages/ - bota um arquivo `.nojekyll` na raiz do repositório (se já não tiver resolvido de outro jeito)

@chesterbr Era isso que estava te escrevendo. Lembrei do Jekyll aqui e ia questionar se os "_" tinham significado especial. Você me confirmou que tem.

Estou usando o Pages da forma você descreveu: via Actions.

Estou fazendo algo muito simples até:

1) gero uma pagina com Hugo
2) gero documentação em HTML com Sphinx (num diretório separado)
3) copio o conteúdo desse diretório separado para dentro de um subdiretório no meu site

Só arquivos estáticos indo de um lugar para o outro.

@chesterbr Pensei em tudo como problema, menos em nomes de diretórios. 😅

@gmgall pois é - na teoria não era pra dar problema, mas aparentemente o Jekyll tá envolvido mais profundamente no processo, então tem que fazer esse "puxadinho" 😅.

Mandou bem de achar, eu ia demorar uma vida (na real eu só me dei conta porque fui fazer um teste no repo do meu site e a primeira coisa que eu vi foi os diretórios do Jekyll com _s)

@chesterbr Então, nem tenho o Jekyll aqui. Foi um daqueles últimos chutes antes de desistir do problema pelo dia.

Veio uma ligeira lembrança que o Jekyll tinha diretórios com "nomes especiais".

Mudei para o branch gh-pages e fiz um commit por cima do feito pelo Actions. Nele só mudava o nome do diretório e as referências para ele. Fiz push e "voilà", a página carregou inteira.