Gitea: Forneça releases e pacotes deb/rpm via Bintray

Nós realmente precisamos de deb/rpm? As imagens do docker não são suficientes? Idk, prove que estou errado! :)

drone só tem imagens docker, certo?

Gogs está usando packager.io, por que não reutilizar isso?

Porque nem todo mundo usa/vai usar o docker.

O Packager.io suporta apenas as versões lts, ​​além disso, o empacotamento do golang pode ser feito muito mais facilmente do que com a sobrecarga do Packager.io.

Ok, eu não sei o suficiente sobre Go. Mas ter uma solução para o Ubuntu 16.04 seria ótimo, pois https://github.com/gogits/gogs/pull/3617 não foi mesclado :(

Para fornecer pacotes para qualquer versão do ubuntu/debian/qualquer que seja, podemos envolver o mesmo binário no pacote e só precisamos ajustar o script init (sysvinit, systemd).

Podemos mesclar o 16.04 packager.io PR e habilitar o gitea nele por enquanto?

Tanto o binário quanto o docker são necessários.

Podemos mesclar o 16.04 packager.io PR e habilitar o gitea nele por enquanto?

Ainda não habilitámos nada por lá, mas como este problema é estimado para 1.0.0, gostaria de apresentá-lo em nosso primeiro lançamento.

Eu também gostaria de versões binárias - não tenho uma configuração de ambiente de desenvolvimento para compilar coisas.

Além disso, poderei atualizar para o gitea de gogs? Eu odiaria perder meus problemas etc.

Teremos versões binárias e esperamos também pacotes para as principais distribuições Linux. Você não precisa compilar nada.

Teremos também binários para a versão master mais recente.

Você poderá iniciar o gitea diretamente com o banco de dados Gogs. Se obtivermos alterações no banco de dados, elas serão migradas automaticamente.

Ooh parece incrível! Estou ansioso então ☺

-- Starbeamrainbowlabs (keybase.io/sbrl)

https://packagecloud.io (OSS — 25 GB de armazenamento / 250 GB de largura de banda + CDN bintray.com 1 TB/m)

@tboerger https://packagecloud.io/docs#os_distro_version LTS e não LTS deb/rpm/etc…
elementary OS / Raspbian / Ubuntu / Debian / SUSE Linux Enterprise Server / openSUSE / Fedora / LinuxMint / Poky distro / Oracle Linux / Scientific Linux / Enterprise Linux (CentOS, RedHat, Amazon Linux)

@denji sim, eu conheço o packagecloud, talvez nós o aceitemos, mas precisamos de um plugin de drone para isso :)

Isso não acontecerá para 1.0.0, então vou movê-lo para 1.1.0.

Gogs já fornece pacotes deb e rpm, então seria uma pena se isso não acontecesse para 1.0.0.

Poderei atualizar o Gogs 0.9.99.0903 para o Gitea 1.1.0 sem problemas?

O Gogs está usando um serviço que suporta apenas as versões lts e que faz alguns agrupamentos binários estranhos. Queremos ter uma solução real.

Acho que você poderia atualizar do Gogs 0.9.99.0903 para o Gitea 1.1.0.

@tboerger que tal fazer algo assim? https://blog.codeship.com/using-docker-build-debian-packages/

@lunny , acho que @jhasse significa atualização em apt-get upgrade

Uma atualização simples do apt-get não funcionará, pois teremos um nome de pacote diferente. Mas acho que funcionará para fazer apt-get remove gogs && apt-get install gitea :)

Então eles têm que copiar o app.ini de Gogs para o Gitea.

Então eles têm que copiar o app.ini de Gogs para o Gitea.

Eles têm que fazer isso antes de apt-get install gitea , caso contrário, o serviço já teria sido iniciado.

@jhasse IIRC regras de empacotamento debian proíbem serviços de habilitação automática na instalação :wink:

Você pode configurar isso: http://askubuntu.com/questions/365911/why-the-services-do-not-start-at-installation

E acho que o padrão no Ubuntu é habilitá-los automaticamente. Pelo menos quando instalei o Gogs no Ubuntu 14.04 não precisei fazer isso manualmente.

É verdade que packager.io faz encapsulamento binário, mas é necessário para gogs/gitea. Várias variáveis ​​de ambiente precisam ser configuradas, etc. Achei o RPM do CentOS 6 gogs muito simples de instalar e configurar.
Seja qual for a solução de embalagem que você escolher para o gitea, certifique-se de que seja fácil de instalar, configurar e atualizar.

Muitos pacotes dependem de variáveis ​​de ambiente, ainda não há necessidade de encapsular o binário. E fácil de instalar e configurar é sempre o foco de um pacote ou não?

Então eu realmente tenho gitea empacotado em um .deb . Não permito nada no meu servidor que não esteja empacotado corretamente. É um pouco de trabalho de retalhos no momento (em parte por causa deste #480).

Sobre o assunto do caminho de atualização... os pacotes .deb permitem que alguns arquivos sejam declarados como arquivos "config" que o gerenciador de pacotes irá:

• Manter após desinstalar o pacote até que o usuário "limpe" explicitamente o pacote
• Verifique se há modificações antes de substituir por uma atualização. Ele perguntará ao usuário o que fazer se a configuração for alterada.

Isso permite que o .deb inclua um arquivo padrão app.ini contendo vários padrões que são diferentes dos padrões principais do gitea (por exemplo: caminhos de arquivo mencionados em #480).

Há também um mecanismo para tornar obsoletos outros pacotes (como gogs), mas isso pode ser menos útil se gogs foi instalado sem um .deb

Para quem estiver interessado em dar uma olhada no meu código de configuração está aqui: https://github.com/couling/gitea/tree/dpkg-config/scripts/dpkg

Eu construo o pacote (com base no arquivo de manifesto no meu config ) usando um script antigo que ainda não joguei de código aberto, mas posso fazer isso em breve se ajudar.

As regras de empacotamento debian do @jhasse IIRC proíbem serviços de habilitação automática na instalação 😉

Isso é interessante. Todos os pacotes do servidor (incluindo coisas como apache2) iniciaram o serviço quando eu instalei.

@couling você poderia enviar um PR?

@tboerger alguma atualização?

Nenhuma atualização até agora do meu lado. IMHO, precisamos executar diferentes contêineres docker para garantir que ele corresponda corretamente ao sistema operacional de destino (referindo-se ao problema da glibc). Além disso, um fluxo de trabalho docker exclui sistemas de 32 bits e outras arquiteturas, pois ainda não podemos oferecer suporte a isso com nossa cadeia de construção.

Então vamos colocar isso na v1.2?

Não tenho certeza se isso é útil. Mas eu tenho uma lib/ferramenta Golang experimental para criar pacotes Debian sem usar o debian (apenas golang nativo). Eu também tive alguns "problemas" ao criar pacotes para o Debian de forma "cross-platform" e não sou um grande fã do dpkg builder. Dê uma olhada: https://github.com/xor-gate/debpkg

Ainda está em fase experimental, mas é capaz de gerar pacotes instaláveis.

@xor-gate obrigado, darei uma olhada quando eu voltar a este problema.

Eu ia tentar empacotar o Gitea para o Debian, mas vejo que alguém me venceu - veja o Debian Bug 79210 .

@mjturner Este tem sido um projeto de cinco meses para mim até agora e na minha taxa atual, pelo menos por muito mais tempo. A maior parte do trabalho não é tão ruim, mas estou preso em alguns lugares-chave que estão destruindo absolutamente minha capacidade de progredir.

Eu preciso de mais ajuda para escrever descrições de pacotes para todas as dependências do gitea que não estão atualmente empacotadas no Debian. Isso está consumindo pelo menos 80% do meu tempo porque minhas habilidades em Golang são fracas e muitos desses deps têm pouca ou nenhuma descrição sobre o que fazem. Eu também tenho lutado com algumas coisas mais debian-build.

Se você, ou qualquer outra pessoa quiser 1. instalar o debian 2. apt-get install gitea, quiser me dar uma mão, sinta-se à vontade para me chamar no IRC! MTecnologia @ Freenode/OFTC

@MTecknology Você me venceu - eu ia enviar um e-mail para você e ver se poderia ajudar de alguma forma. Eu tenho uma quantidade razoável de experiência em empacotamento Debian (sou um desenvolvedor emérito), embora nenhum com aplicativos de empacotamento Go, e uma quantidade razoável de experiência em desenvolvimento Go. Entraremos em contato via IRC em breve

@mjturner parece que te assustei! Se você ainda estiver interessado, estou em um lugar onde isso está ficando um pouco esmagador e eu realmente poderia usar uma mão.
ou .. mais alguém? Alguém que entende de empacotamento Debian e/ou Go? Por favor?... :cry:

Olá pessoal, o empacotamento do debian não é muito intuitivo porque é muito, muito flexível. A maioria das pessoas quer apenas alguns arquivos dentro de um .deb e alguns meta (pacotes, versão, descrição). Eu acho que a maneira mais rápida é usar algumas ferramentas de frontend para construir um pacote debian simples. Por exemplo, https://github.com/laher/goxc ou https://github.com/jordansissel/fpm.

Os caras do Syncthing (projeto golang) usam o FPM para construir um pacote debian em seu script build.go :
https://github.com/syncthing/syncthing/blob/2579e8f7152c3205691f3798a81d43c1af4e8af6/build.go#L531 -L539

Algumas pessoas já colocaram algum esforço no sistema de compilação do debian Make para ter um dh-make-golang (debian helper make for golang), veja https://github.com/Debian/dh-make-golang.

Ele precisa de um pouco de amor para empacotar para o debian, mas vale a pena o esforço.

@MTecknology Desculpas! Definitivamente, não fiquei com medo, fiquei tão sobrecarregado com uma tonelada de outras coisas que não tive a chance de dar outra olhada em Gitea desde nosso último contato há algumas semanas :(

Meu tempo ainda é bastante limitado no momento, mas ainda estou muito interessado em me envolver.

Sem problemas. Este projeto é mais do que qualquer pessoa razoável, sã ou bem ajustada deveria tentar realizar. No momento, acho que estou lidando com incompatibilidades de versão em que a compilação é bem-sucedida, mas os resultados do tempo de execução são uma falha de segmentação. Pelo menos é finalmente uma compilação em conformidade com a política.

Acontece que eu preciso de algumas bibliotecas javascript adicionais empacotadas. Mais... woohoo..... :sob:

@MTecknology Alguma chance de você compartilhar seus pacotes WIP atuais (por exemplo, via repositório público)? Pode ajudar a incentivar o envolvimento de outras pessoas.

@mjturner heheh... você realmente postou um link para onde eu postei um link para o meu WIP (o bug do debian)
--> https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress

Não houve nenhuma mudança significativa desde o meu último comentário neste tópico. Eu consegui obter uma compilação real, mas segfaults. Eu tenho um palpite bastante sólido de que as falhas de segmentação foram por causa de versões de biblioteca incompatíveis. Eu tenho a maioria (~ 90) das novas dependências de compilação incluídas na instável, mas preciso esperar até depois do congelamento antes de poder considerar atualizar qualquer coisa. (em breve)

No momento, preciso de mais ajuda com pacotes/dependências javascript.

Isso vai ser retido pelo #1484, entre outras coisas, mas o Debian 9 foi lançado e estou planejando começar a fazer algum progresso novamente em um futuro próximo. Ainda há muito o que fazer, mas um dia vou fechar esse otário!

Olá, alguém já fez rpm com sucesso no fedora/centos/rhel?

@tboerger - Eu realmente amo o que você e sua equipe estão fazendo com a Gitea! Para resolver as preocupações das pessoas com o Gitea ainda não ter RPMs, escrevi uma ferramenta para gerar Gitea RPMS para os derivados Red Hat 6.xe 7.x. Estou testando localmente há algum tempo e estou muito perto de lançá-lo no próximo dia ou dois.

Não tenho certeza se você está procurando uma solução GO para construir RPMS ou se deseja apenas um processo que construa RPMs. Minha ferramenta (mesmo que seja escrita principalmente em python) irá gerar RPMS que estão em conformidade com os padrões de empacotamento da Redhat.

Não tenho certeza se você está aberto a usar essa ferramenta, mas planejo colocar meu gitub público no próximo dia ou dois.

Estamos sempre abertos a relações públicas, mesmo que não sejam fundidos, podem ser úteis para outros. Você pode usar a pasta contrib para armazenar seu script. No geral, tentamos mantê-lo em golang, mas para casos específicos, fazemos exceção e python é uma ferramenta comum.

@codylane ansioso por isso! Eu estava trabalhando em fazer isso usando a forma de embalagem do fedora, mas eu mal sei como fazer isso e seria um tiro no escuro.

Certo, fico feliz em saber que isso pode ser útil para as pessoas. Estou terminando o readme, mas devo tê-lo na minha conta pública do github hoje à noite. Compartilharei o link assim que estiver disponível.

Eu ficaria feliz em enviar uma solicitação de pull para o gitea, apenas imaginei que a comunidade poderia me ajudar a garantir que funcione antes de entrar no seu repositório. Eu tenho muitos testes de integração em torno do RPM, mas a melhor maneira de garantir que funcione é chegar na frente das pessoas. :)

Obrigado novamente por criar uma ferramenta de código aberto tão incrível!

Talvez isso também possa ser algum trabalho de base para um plugin de drone, já conversei com outro dev que criou um plugin deb para drone.

Legal. Eu também preciso fazer o checkout do drone e está na minha lista de coisas para brincar.

Conforme prometido, aqui está um processo de CI automatizado para criar o Gitea RPM para CentOS 6 e 7. https://github.com/codylane/gitea-rpm.

Por favor, deixe-me saber se você perguntas ou preocupações ou se houver algum problema. Eu já abri um pequeno problema com o systemd. Vou consertar isso amanhã.

Já pensou em usar Copr ?

Talvez quem possa enviar um PR para alterar o arquivo do drone para gerar deb? @tboerger @bkcsoft @appleboy

@jhasse do que também podemos usar o open buildservice. Eu não acredito que essas ferramentas são a melhor seleção.

Eu preferiria um plugin de drone para rpm e deb e hospedaria os repositórios por conta própria ou no bintray/packagecloud

@tboerger - Apenas curioso, você gostaria que eu desse uma facada nas coisas do drone? A razão pela qual eu pergunto é porque eu estava pensando em conectar meu repositório ao TravisCI. Eu entendo totalmente se vocês preferirem um serviço de construção independente. :)

Se você quiser que eu analise o drone, você poderia compartilhar alguma documentação sobre como sua equipe o está usando? Eu sou grande em padrões e não gosto de recriar a roda se eu não tiver também.

Atualmente estamos usando principalmente plugins criados por contribuidores de drones da org github drone-plugins, @thomasf começou a construir drone-deb para empacotamento baseado em Debian e eu gostaria de iniciar um plugin drone-rpm dentro da org drone-plugins.

Você pode ver nosso .drone.yml na raiz do projeto, estamos hospedando nossa instância de drone em drone.gitea.io

Legal. Depois de corrigir esse problema do systemd, darei uma olhada como você recomendou. Obrigado cara!

FYI - O problema do systemd foi resolvido e os RPMs devem estar em boas condições de funcionamento. Ainda preciso dar uma olhada no material do drone.

Apenas jogando em outra idéia para fornecer um meio simples de instalação através de um "pacote" no Linux: http://linuxbrew.sh.

Olá, alguma novidade sobre os pacotes deb? Eu realmente adoraria ter um pacote gitea deb ;)
Na verdade, eu precisaria deles para o Ubuntu 16.04 e o Ubuntu 18.04, apenas para ser mais preciso ...

Também estou disposto a fazer o pacote debian e disponibilizá-lo se este passo não tiver sido feito antes, é só me avisar ;)

Este problema foi marcado automaticamente como obsoleto porque não teve atividade recente. Será fechado se não ocorrer mais nenhuma atividade durante as próximas 2 semanas. Obrigado por suas contribuições.

Obrigado stalebot por sua contribuição.

Ainda estou promovendo meu pacote github.com/xor-gate/debpkg go para empacotamento debian 🎉 .

@xor-gate você poderia enviar um PR para adicionar um arquivo de configuração para sua biblioteca no contrib? Talvez pudéssemos lançá-lo em um plugin de drone.

Este problema foi marcado automaticamente como obsoleto porque não teve atividade recente. Será fechado se não ocorrer mais nenhuma atividade durante as próximas 2 semanas. Obrigado por suas contribuições.

Por favor, considere como demanda para isso...

Apenas obsoleto por causa da falta de uma solução.

Eu não acho que qualquer pessoa tenha energia suficiente para manter o gitea embalado para
Debian main, existem muitas dependências com o golang típico
problemas do ecossistema [1]. Passei mais de um ano com > 30 horas/semana tentando fazer isso
acontecer; quando desisti, levou menos de três meses para as libs que eu
empurrado para o Debian para ser retirado do arquivo devido a alterações
dependências.

Eu poderia ajudar alguém a manter isso de graça (ou principal se um masoquista
equipe se apresenta), mas precisaria vir com um alerta sobre a falta
de estabilidade, por muitas razões.

[1]

• Algumas bibliotecas estão mortas, com bugs de segurança contra elas
• Muitas libs foram bifurcadas com níveis variados de manutenção (principalmente
  remendar e esquecer)
• Novas bibliotecas são adicionadas arbitrariamente, muitas vezes com pouca ou nenhuma revisão
• 'ir vendedor' (curl | sudo -)
• Os >200 deps golang raramente fornecem lançamentos (esperando que os aplicativos sempre
  puxe o git mais recente, incluindo quaisquer bibliotecas de deps adicionais adicionadas)

Além disso-

• Parece não haver nenhum método para coordenar atualizações de segurança (com o
  mentalidade de que a atualização mantém você seguro ... faz o oposto)
• As > 200 golang libs empalidecem em comparação com as > 2.000 js libs
• Há uma terrível falta de preocupação quanto ao que pode legalmente ser incluído na
  software livre
• Os esforços para corrigir esses problemas encontraram resistência significativa

Embora seja possível empacotar o gitea para distribuições que não se importam
esses problemas de licenciamento e compatibilidade, desisti quando percebi
nunca pode sobreviver no Debian main sem uma equipe de masoquistas com um
muito tempo disponível, para mais do que apenas o lançamento inicial.

Mais uma vez, fico feliz em ajudar qualquer pessoa interessada, mas, pessoalmente, migrei para
produzindo um "clone" mais minimalista que remove esses problemas. (Lento
indo por causa do pouco tempo disponível)
... Se alguém estiver interessado no meu projeto ou trabalhando no gitea para
Debian, entre em contato com MTecknology no Freenode.

>

@MTecknology existe um PR para resolver esse problema. veja https://github.com/go-gitea/gitea/pull/6671 .

Ele não resolve nenhum dos problemas que mencionei, apenas os apresenta em um pacote conveniente que ainda é inadequado para o repositório Debian.

E que tal fornecer um ppa (que hospedaríamos) para fornecer pacotes debian construídos automaticamente?

Teria pensado que as bibliotecas JS seriam empacotadas com o próprio gitea - sempre evitei as versões das chamadas bibliotecas javascript disponíveis via apt, porque você não pode garantir qual versão é essa.

Quanto às bibliotecas go, pensei que o Gitea lançou apenas um único binário? É o que tenho usado, pelo menos. Um repositório apt simples não poderia ser criado com um pacote que contém esse único binário?

Isenção de responsabilidade: Eu _não_ sou um mantenedor do debian, e tenho uma experiência bastante limitada em empacotar coisas em arquivos .deb. Minha experiência vai até fpm

@MTecknology Você fez uma enorme quantidade de trabalho, mas infelizmente eu sinto que não necessariamente faz sentido empacotar o gitea para o debian. Não há um objetivo no projeto de suportar versões antigas com segurança ou correções de bugs que correspondam aos ciclos de lançamento do debian. E como você mencionou, a quantidade de dependências é incontrolável. O provérbio "Um pouco de cópia é melhor do que um pouco de dependência." foi ignorado. Mas isso também é bastante compreensível, pois é um esforço voluntário com poucos recursos para coisas como manter as dependências atualizadas ou refatorar o código copiado para incluir apenas as coisas necessárias e depois fazer o backport das correções. E o mundo de dependências JS/NPM é ainda pior. Acredito que softwares como o gitea são melhores oferecidos como imagens docker que funcionam em várias distribuições linux. Espero que as imagens do docker estejam bloqueadas, pois o código ainda apresenta os problemas com dependências e correções de segurança que você mencionou.

Forneça um repositório yum e a fonte apt será outra com um script de shell de instalação será outra opção.

Claro que seria legal ter o gitea nos repositórios oficiais do Debian ou Ubuntu, mas como já foi dito acima isso resulta em muito trabalho.

Para evitar esse pesadelo de empacotamento, poderíamos simplesmente construir pacotes deb e rpm que são fornecidos via bintray ou mesmo através de alguma pasta no espelho de download que é apoiada pelo cdn cloudflare.

Os pacotes em si podem ser construídos via fpm, ou alguém contribui com um plug-in de drone que pode até pousar na organização de plug-ins de drone se estiver escrito em go e tiver alguns padrões. Existe até uma biblioteca go que implementou muitos recursos fpm.

Em termos de empacotamento formal para distribuições, embora isso possa e provavelmente deva ser um objetivo de longo prazo, não acho que devamos necessariamente fazer isso no momento. Nossa base de código ainda está mudando rapidamente e acho que no momento não podemos nos comprometer a manter as versões muito antigas que acabariam sendo empacotadas formalmente com essas distribuições.

Também estou preocupado com o número de dependências externas que temos - definitivamente devemos pensar se precisamos delas como dependências rígidas (por exemplo, gorgeous, boltdb) e se algumas de nossas dependências menores podem se beneficiar de serem bifurcadas ou reescritas. (Sessão Macaron e go-ini são ambos imho problemáticos.)

Também precisamos refatorar nossa estrutura interna para tornar os plugins go uma realidade. Isso eu acho que nos permitiria fazer um core-gitea mais enxuto que poderia ser empacotado sem trazer todas as outras dependências.

Embalar corretamente os projetos Go é em qualquer distribuição um PITA. É por isso que devemos apenas construir o binário e fornecer pacotes simples que ignoram as melhores práticas das distribuições para empacotar cada dependência como um pacote separado.

Falando como mantenedor do Debian, seria muito bom ter o gitea no Debian como pacote em si. Mas há problemas técnicos (e talvez de licença) com ele, então isso está fora do escopo deste problema.

Falando como usuário Debian, seria legal enviar o gitea via pacote deb. Como já temos um binário estático, ele pode ser enviado nele. O avanço disso é que também podemos incluir infraestrutura adequada, como arquivos de unidade, para iniciá-lo na inicialização do sistema e talvez uma configuração padrão sã, se necessário.
Para a maioria das pessoas, significa adicionar uma fonte de pacote, adicionar uma chave de assinatura e apenas instalar o pacote. As atualizações são implantadas de uma maneira que os usuários já conhecem.

RPMs do CentOS: https://cbs.centos.org/koji/buildinfo?buildID=25894

Seria ótimo colocar um rpm em um repositório dnf/yum atualizado com frequência para que os usuários da distribuição rpm possam ficar atualizados com atualizações de segurança, etc., para o gitea.

@waja Alguma mudança no seu pacote CentOS sendo atualizado para o Fedora e possivelmente adicionado ao EPEL se for testado e estável?

Alguma novidade sobre isso? Um mês atrás @techknowlogick em #6671 disse que o Drone poderia ser usado para compilações automatizadas de rpms e debs. Alguém conseguiu encontrar um momento para habilitá-lo? Se sim, poderia atualizar a documentação?

@Janhouse Eu tenho tentado empacotar isso para o Fedora, mas o Go é uma dor para ser empacotado corretamente. A versão do CentOS vinculada acima não foi construída corretamente para mim e notei algumas mudanças que precisavam acontecer com ela.

Ainda estou interessado em compilações oficiais adequadas, pois garante que os pacotes sejam melhor mantidos.

@waja não sabe muito sobre como colocar um projeto no repositório oficial do debain, mas o alpine-linux já tem um pacote funcional: source

Nós não vamos colocar o gitea nos repositórios oficiais do Debian, é um esforço realmente grande que já falhou no passado.

Quão difícil é manter um ppa?

Não é particularmente difícil, @ 6543. Na verdade, eu tenho meu próprio repositório apt aqui: https://apt.starbeamrainbowlabs.com/

O código que uso para gerenciá-lo pode ser encontrado aqui: https://git.starbeamrainbowlabs.com/sbrl/aptosaurus

Se alguém tiver um script Bash que baixa automaticamente os arquivos de lançamento do GitHub, verifica os hashes SHA256 e os empacota com fpm , ficarei feliz em executá-lo sozinho (embora não tenha certeza de poder hospedar versões de pacotes anteriores; Gitea é bastante grande e o espaço de armazenamento aumenta rapidamente).

A construção do pacote deve ser feita por drone, e então deve ser simplesmente carregado no bintray ;)

@tboerger vou tentar fazer um rascunho de PR com o script de compilação deb ...
& temos dl.gitea.io vale a pena fazer o upload do deb lá também (e talvez como anexo no lançamento)

Eu pessoalmente não gostaria de gerenciar repos deb e rpm por conta própria, é por isso que o Bintray seria ótimo para isso. Apenas enviar um arquivo deb ou rpm sem nenhum repositório é IMHO bastante inútil.

Apenas enviar um arquivo deb ou rpm sem nenhum repositório é IMHO bastante inútil.

é completamente absurdo!

Também poderíamos usar nfpm para construir arquivos deb e rpm

Alguém já começou há algum tempo a construir um plugin fpm drone... Eu ainda quero construir um dentro do plugins org baseado no fork go fpm.

Aqui está um plugin de drone que fiz para nfpm: https://github.com/techknowlogick/drone-nfpm

Se você fizer pacotes para sistemas FHS, lembre-se de usar o script de sombreamento em contrib ou construir com o LDFLAGS configurado corretamente.

Olá a todos, eu tenho meu próprio repositório de pacotes APT, posso adicionar gitea nele.
Veja o projeto já incluso: https://packages.azlux.fr/
Agora está rodando, é fácil adicionar qualquer .deb que você quiser (eu posso até criá-lo)

Azlux

@azlux tudo se resume à confiança. Você provavelmente é um cara legal, mas eu prefiro instalá-lo de algum serviço de automação conhecido, onde os scripts de compilação são mantidos pela equipe de desenvolvimento do gitea, do que obtê-lo de algum repositório privado. Eu tenho meus próprios pacotes construídos também, mas idealmente eles seriam gerenciados pela equipe do gitea.

Gancho
Obrigado pela informação @Janhouse
Configurei meu repositório com o reprepro, posso ajudar se precisar.

Az

@Janhouse Após uma reflexão mais profunda, o repositório apt nos permite verificar se as fontes não foram modificadas nesse meio tempo. Idealmente, é melhor ter o gitea mantendo seu próprio repositório, mas eles também podem colocar outro repositório como "repositório não oficial".
Muitos projetos não têm problemas com isso. Assim, as pessoas advertiram.

Eu sei que já disse isso antes, mas...

Se você estiver fornecendo pacotes Deb, provavelmente deve compilar o Gitea para que ele obedeça ao FHS definindo o LDFLAGS conforme descrito aqui:

https://docs.gitea.io/en-us/install-from-source/#change -the-default-custompath-customconf-and-appworkpath

O mesmo aqui - eu tenho um repositório de apt pessoal no qual posso hospedar

Eu também gostaria de ver o gitea seguir o FHS @zeripath , é bobo eles precisam de um script de shell wrapper para fazer isso também.

Alguma notícia sobre RPMs enquanto isso? Vejo muita discussão sobre DEBs, mas muitas empresas usarão o CentOS que não usa pacotes DEB. Os BSDs parecem ter seus próprios pacotes (com patches), mas seus processos são um pouco diferentes.

@evitalis , você não precisa de um script se o compilar com o LDFLAGS apropriado.

Eu sei, eu estava me referindo à necessidade deles de ter isso .

Apenas pensando nisso. O caminho FHS deve ser o padrão para v2, pois seria uma alteração necessária.

Acho que precisamos quebrar um pouco isso. Existem quatro tipos de construção atualmente:

• builds de desenvolvimento - você baixa o código-fonte e constrói com make
• compilações pessoais - você baixa a fonte e compila com make, mas deseja que este seja um servidor em execução
• builds de lançamento - construímos com make release e mantemos no gitea.io e GH
• compilações do docker

FHS por padrão faz sentido para até 2 deles: release e possivelmente pessoal - mas no momento você não pode dizer se uma compilação pessoal é uma compilação de desenvolvimento ou vice-versa. Quebrar as compilações de desenvolvimento seria uma ideia muito ruim.

O Docker também deve ter seus padrões incorporados - não faz sentido exigir "-c" por padrão em uma compilação do docker que construímos.

Existe a possibilidade de mudar para onde olhamos por padrão, dependendo de onde o binário é colocado - mas suspeito que isso possa ser uma má ideia. Acho que teria que verificar novamente qual é a prática normal para isso. (hierarquias de pesquisas de configuração? - ugh complexo)

Quando fiz a opção LDFLAGS funcionar pela primeira vez, propus:

• Faça uma versão separada com caminhos FHS incorporados
• Faça com que o docker tenha os caminhos padrão para o docker incorporado - o que resolve alguns outros problemas estranhos com a execução do gitea na linha de comando do docker.
• Adicione/exponha um ponto final make para compilações FHS que defina os sinalizadores corretamente <- Os construtores de pacotes devem usar isso...

Estas são mudanças ininterruptas que não necessariamente exigiriam esperar pelo 2.0 - estamos apenas adicionando uma nova opção de download.

Uma alternativa é adicionar um script de configuração e criar endpoints de instalação - pois isso pareceria "normal" para pessoas acostumadas a:

# get source by whatever means necessary
cd gitea
./configure
make
sudo make install

É absolutamente normal pesquisar em caminhos predefinidos para configurações se você não fornecer um sinalizador para um caminho personalizado. Isso é um exemplo que já faz parte de https://github.com/spf13/viper para definir vários caminhos padrão. O atual comportamento fodido de Gitea é totalmente incomum.

Talvez valesse a pena colocar as compilações de lançamento nos repositórios primeiro seria um bom primeiro passo?

@sbrl já feito no meu repositório, o script de compilação está armazenado aqui: https://github.com/azlux/dpkg-deb
Como você disse, ele usa diretamente o build de lançamento.

@zeripath Acho que você está tornando isso mais complicado do que o necessário com base na sua resposta, mas posso estar interpretando mal. Se as pessoas estão executando git clone e construindo coisas por conta própria, devem saber que problemas podem acontecer. Para muitos projetos, fazer essa compilação do branch master ou usar uma versão é considerado estável, qualquer outra coisa não é e pode quebrar a qualquer momento.

Mesmo no Docker, não há motivo para não seguir o FHS, então esse caso também desaparece. Para o resto, conforme observado por @tboerger , a verificação de um conjunto padrão de caminhos para uma configuração é considerada normal. Confiar apenas em $PWD ou em sinalizadores de compilação aleatórios que a maioria dos usuários nunca verá causa mais problemas, inclusive com o empacotamento do sistema operacional. Como alguém que empacotou mais do que algumas coisas, quanto menos padrão o aplicativo, mais trabalho para mim e mais patches eu posso ter que introduzir.

Com tudo isso dito, ainda estou interessado em ver pelo menos os RPMs oficiais. Eu não uso Debian ou Ubuntu, mas tenho certeza de que um DEB oficial também seria bem-vindo. Obrigado a todos neste tópico fazendo o seu melhor na embalagem nesse ínterim.