Como publicar seu software no Copr, o Repositório de Usuários do Fedora

Faça um push dos commits e tags para o remoto usando `git push --follow-tags`, e com isso estamos prontos para lançar o pacote no Copr.

== Segundo passo: Publicando o pacote em um repositório Copr

. Vá para https://copr.fedorainfracloud.org/ e faça login. Uma vez que esteja logado, clique em _New Project_ (Novo Projeto) e comece a criar um repositório para nosso programa. Nas entradas de input a seguir,

.. Em _1. Project information_ (Informações do projeto) -> _Project name_ (Nome do projeto) defina o nome de como você quer que seu repositório se chame - já que ele conterá apenas um único pacote, faz sentido usar nomedoprojeto = nomedopacote, nesse caso _hellocopr_. Essa é a única configuração que não pode ser modificada depois.

.. Em _2. Build options_ (Opções de build) marque todas as distribuições para as quais você deseja criar repositórios - geralmente todas as versões do Fedora e talvez versões para o EPEL também

.. Em _4. Other Options_ (Outras Opções) garanta que _Follow Fedora branching_ (Seguir ramificação do Fedora) está marcada, isso garantirá que seu repositório será automaticamente atualizado para cada novo lançamento do Fedora.

. Vá para _Packages_ (Pacotes) -> _New Package_ (Novo Pacote)

.. Em _1. Provide the source_ (Adicione a fonte), defina o nome do pacote e a URL do seu repositório git

.. Em _2. How to build SRPM from the source_ (Como construir o SRPM a partir da fonte) selecione _tito_

.. Em _3. Generic package setup_ (Configurações genéricas do pacote) marque a opção de _Auto-rebuild_ (Reconstrução automática)

. Seu pacote aparecerá na lista de pacotes. Selecione _Rebuild_ para iniciar uma construção. A página a seguir lhe permite mudar quaisquer opções de build se necessário, mas iremos utilizar apenas os padrões, ou seja, as opções que configuramos no último passo. Clique em _Submit_ (Confirmar) e o Copr construirá o pacote a partir da tag do tito que criamos no Primeiro passo.

Uma vez que a construção estiver finalizada, você pode experimentar instalar o pacote através do Copr ativando seu repositório. ``` user@host ~/copr-tito-quickdoc % sudo dnf copr enable <username>/hellocopr

user@host ~/copr-tito-quickdoc % sudo dnf install hellocopr ```

== Terceiro passo: Automatizando a (re)construção do pacote

Em seguida, vamos configurar o Copr para construir automaticamente uma nova versão do pacote quando criarmos uma, para que não precisemos fazer login e iniciar uma manualmente. Para fazer isso, precisamos simplesmente iniciar uma construção quando fizermos push de uma nova tag para o repositório.

Isso requer uma certa configuração tanto do seu repositório Git e do seu projeto Copr.

A configuração no Copr pode ser encontrada em _Settings_ (Configurações) -> _Integrations_ (Integrações), a página também explica os passos para configurar seu repositório git para todas as _forges_ Git mais comuns (Pagure, GitHub, GitLab e BitBucket).

Agora, para testarmos, vamos fazer algumas mudanças no nosso programa que virão a calhar para a última camada de automação e criar uma nova atualização para nosso software.

Atualmente o programa de exemplo tem sua versão manualmente definida em inúmeros lugares. link:https://pagure.io/copr-tito-quickdoc/c/61abf1cdf622d8c9fb4f03eb6b06c4ddc1677362?branch=master[Vamos mudar isso] para que a string de versão seja modificada por um único arquivo. Não importa que arquivo seja, mas idealmente a variável de versão deve ser a única coisa que provavelmente mudará. Nesse caso, vamos usar o arquivo `src/hellocopr/pass:[__]initpass:[__].py` que anteriormente estava vazio. Vamos nomear essa nova versão '1.0.1'.

Faça um commit das mudanças, e crie um novo lançamento com tito

Note que ao omitir a opção `--use-version`, tito agora atualiza a versão automaticamente. Ele o faz

. Aumentando o dígito final da versão em 1 - `1.0.0` -> `1.0.1`
. Resetando o lançamento para 1 se já não foi feito antes.

Se você quiser aumentar para uma versão diferente, por exemplo `1.1.0`, você pode fazê-lo passando novamente `--use-version`.

Faça push do commit e da tag resultantes, e se você conferir a página do seu projeto no Copr, você verá que uma nova build do `hellocopr-1.0.1-1` foi iniciada por termos feito push da tag.

== Quarto passo: Deixar o tito gerenciar a versão do programa

Se você chegar o log do git, você vai descobrir que eu na verdade esqueci de atualizar a variável de versão do hellocopr para 1.0.1. Não queremos que isso aconteça novamente. Por sorte, já que fizemos o processo de modificação da versão para uma única fonte, podemos deixar o tito gerar esse arquivo automaticamente a partir de um template.

First, copy the version source file `src/hellocopr/pass:[__]initpass:[__].py` to `.tito/templates/pass:[__]initpass:[__].py.template`. Then, open the template file and replace the version string with `$version`. It also makes sense to add a note that the file is managed by tito and should not be edited manually. ``` user@host ~/copr-tito-quickdoc % cat .tito/templates/__init__.py.template ... # This file is automatically created from a template by tito. Do not edit it manually.

__version__ = '$version' ```

Next, add the following to `.tito/tito.props` ```
[version_template]
destination_file = src/hellocopr/__init__.py template_file = .tito/templates/__init__.py.template ``` https://pagure.io/copr-tito-quickdoc/c/28600f6e41d5a4b60f2e47cf077f2fe2d9224e1d?branch=master[Commit the changes]. Now, when we tag a new release, tito will take the template, replace `$version` with whatever version was tagged, and copy the resulting file to `src/hellocopr/pass:[__]initpass:[__].py` before updating the spec file and commiting the changes.

We can test this by tagging a new release: