Synchronize publishing of release artifact files
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
Direção de pesquisa
Comece mapeando a automação de releases e as três funções da release team descritas na issue, incluindo as transferências para o download server. Revise as etapas do RM para produzir arquivos sigstore, atualizar o release database com addfiles e anunciar uma release. O trabalho estará concluído quando o RM puder acionar uma única etapa final de publicação depois que todos os artefatos estiverem prontos.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
There are some timing holes in the current cPython release process which, while somewhat minor, could be tightened up. Currently, there are three release team member roles in producing downloable artifacts for a release and each is responsible for ensuring that their artifacts have been moved into the final file system location on the download server. Once they have done that, those subsets of the release artifacts become immediately available to download, independent of any release notice. Since the three release team members in general work asynchronously once the RM tags the release engineering branch, it is unpredictable when various release files appear on the download server. The release automation waits at various points for the artificats to show up there, also independent of any manual (email) notification to the RM.
It is up to the RM to finish things off and produce the sigstore files, update the release database (addfiles), and announce the release. But because the URLs of the downloadable files for each release are generally predictable, there are some downstream users and likely bots that can poll for these files becoming available. This can, on infrequent occasions, be an issue if some problem is discovered late in the release process, for example, a problem that is discovered while testing the macOS installer or the Windows binaries, that may require a re-spin of the entire release.
Granted users shouldn't be using things before they are officially announced, but they will. It would be better if we modified the process somewhat so the RM is responsible for triggering the final step of making all of the downloadable artifacts publically available after all the pieces are in place.
- Linguagem predominante
- Python
- Estrelas
- 61
- Forks
- 48
- Merge médio
- 1h 22min
- PRs com merge (30d)
- 4
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de python/release-tools
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
python/release-tools#401 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 25/100
python/release-tools#434 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 38/100
python/release-tools#417 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 68/100
python/release-tools#397 ·
-
bug
python/release-tools#286 · 1 responsável ·
Todas as issues de python/release-tools
Issues semelhantes
-
agent-ready documentation needs-triage
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 88/100
-
documentation
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Aberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 92/100
-
instance instance add
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 72/100
searxng/searx-instances#939 · 1 comentário ·
-
area-deployment area-integrations triage:bot-seen
Dificuldade 2/5 Meio dia Facilidade para iniciantes 86/100