chore: fixa scielo_scholarly_data na tag v0.1.4 (fase 7, #1251) - #1286
Open
Rossi-Luciano wants to merge 1 commit into
Open
chore: fixa scielo_scholarly_data na tag v0.1.4 (fase 7, #1251)#1286Rossi-Luciano wants to merge 1 commit into
Rossi-Luciano wants to merge 1 commit into
Conversation
Fase 7 da estrategia de atualizacao de dependencias: fixa scielo_scholarly_data, que estava como -e git+... sem ref (resolve sempre para o HEAD da branch default no momento da instalacao, sem reprodutibilidade garantida entre builds). Investigacao (via gh api): o repo scieloorg/scielo_scholarly_data nao recebe commits desde 2022-06-10. O HEAD atual da branch main e exatamente o commit da tag v0.1.4 (release oficial, nao rascunho, publicada em 2022-05-18). Ou seja, fixar em v0.1.4 resolve para o mesmo commit exato que ja esta em uso hoje, sem nenhuma mudanca de comportamento -- so remove a dependencia de reprodutibilidade em relacao ao estado futuro (imprevisivel) do branch default do repo upstream. Nao foi necessario abrir pergunta bloqueante na issue: nao ha ambiguidade editorial aqui, e uma correcao tecnica direta (fixar no que ja esta em uso). Validado com pytest completo (venv isolado, so scielo_scholarly_data alterado, resto igual ao master): duas rodadas deram 40 failed, 5973 passed, 30 skipped, identico ao baseline (a primeira mostrou 44 failed pelo flake ja conhecido de test_i18n.py, que sumiu na segunda rodada). Confirmado tambem que o commit instalado antes e depois da mudanca e byte-identico (a2899ce8...).
16 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O que esse PR faz?
Fase 7 da estratégia de atualização de dependências definida na issue #1251: fixa
scielo_scholarly_datana tagv0.1.4, em vez de-e git+...sem nenhuma referência (o que resolve sempre para o HEAD da branch padrão no momento da instalação, sem reprodutibilidade garantida entre builds).Investigação
O repositório
scieloorg/scielo_scholarly_datanão recebe commits desde 2022-06-10. O HEAD atual da branchmainé exatamente o commit da tagv0.1.4(release oficial, não rascunho, publicada em 2022-05-18). Ou seja, fixar emv0.1.4resolve para o mesmo commit exato que já está em uso hoje: zero mudança de comportamento, só remove a dependência de reprodutibilidade em relação ao estado futuro (imprevisível) do branch padrão do repo upstream.Como não há ambiguidade editorial aqui (é uma correção técnica direta, fixar no que já está em uso), não abri pergunta bloqueante na issue.
Onde a revisão poderia começar?
requirements.txt, único arquivo alterado.Como este poderia ser testado manualmente?
Deve dar o mesmo resultado do master (40 failed pré-existentes, 5973 passed, 30 skipped).
Algum cenário de contexto que queira dar?
Independente das fases 1-6: parte direto do master.
Achado à parte (fora do escopo desta correção pontual): o repositório upstream
scielo_scholarly_dataparece abandonado há mais de 3 anos (nenhum commit desde 2022-06-10). Vale considerar, em algum momento, se packtools deveria vendorizar/absorver essa dependência em vez de continuar dependendo de um repositório externo sem manutenção.Validação:
pytestcompleto com venv isolado (só essa linha alterada, resto igual ao master). Duas rodadas deram 40 failed / 5973 passed / 30 skipped, idêntico ao baseline (a primeira rodada mostrou 44 failed pelo flake já conhecido detest_i18n.py, que sumiu na repetição). Confirmei também que o commit instalado antes e depois da mudança é byte-idêntico (a2899ce8...).Screenshots
N/A (mudança de dependências, sem interface).
Quais são os tickets relevantes?
Parte de #1251 (fase 7 da estratégia de atualização de dependências).
Referências
Estratégia priorizada descrita nos comentários de progresso da issue #1251.
Segurança da informação (NSI.04)
Este PR manipula dados sensíveis ou pessoais (LGPD)?
Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?
Este PR introduz, atualiza ou remove dependências de terceiros?
Sim — as novas dependências foram verificadas no SBOM/Trivy sem vulnerabilidades críticas/altas em aberto?
Este repositório não usa Trivy/SBOM (é biblioteca, não serviço containerizado, conforme
SECURITY_ADHERENCE.mdseção 3). O gate real de dependências é o Snyk, que roda automaticamente neste PR. Não há mudança real de código nesta dependência (mesmo commit antes e depois), apenas fixação de versão.Não
Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?
SECURITY_ADHERENCE.mdseção 3). Os gates automáticos reais (Snyk e GitGuardian) rodam neste PR.Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?
Este PR expõe novos endpoints, telas ou serviços?
Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?