gitea/snap/snapcraft.yaml

86 lines
2.4 KiB
YAML
Raw Normal View History

name: gitea
summary: Gitea - A painless self-hosted Git service
description: |
The goal of this project is to make the easiest, fastest, and most painless
way of setting up a self-hosted Git service. With Go, this can be done with
an independent binary distribution across ALL platforms that Go supports,
including Linux, Mac OS X, Windows and ARM.
icon: public/img/logo-lg.png
confinement: strict
base: core18
adopt-info: gitea
architectures:
- build-on: armhf
- build-on: amd64
- build-on: arm64
environment:
GITEA_CUSTOM: "$SNAP_COMMON"
GITEA_WORK_DIR: "$SNAP_COMMON"
GIT_TEMPLATE_DIR: "$SNAP/usr/share/git-core/templates"
GIT_EXEC_PATH: "$SNAP/usr/lib/git-core"
apps:
gitea:
command: gitea
plugs: [network, network-bind]
web:
command: gitea web
daemon: simple
plugs: [network, network-bind]
dump:
command: gitea dump
plugs: [home]
version:
command: gitea --version
sqlite:
command: usr/bin/sqlite3
parts:
gitea:
plugin: make
source: .
stage-packages: [ git, sqlite3, openssh-client ]
build-packages: [ git, libpam0g-dev, libsqlite3-dev]
build-snaps: [ go, node/14/stable ]
build-environment:
- LDFLAGS: ""
override-pull: |
snapcraftctl pull
Add logic to build stable and edge builds (#12052) This adds some logic to enable the snapcraft builds of the gitea snap to create both builds of the latest tip of master for edge channels, and stable releases. The logic simply looks for a new upstream release in github, and if that latest tagged release is not the same as the release in the candidate channel in the snap store, then it must be new, and so we checkout that tag and build that. If the current released tag is the same as what's in candidate, we build whatever is in git master. The process for using this is: Initially: When this lands, it will build the latest stable release of gitea and push to the edge channel in the snap store. Someone on the release team can go to https://snapcraft.io/gitea/releases and release that build to stable and candidate. Ongoing: The next build to be triggered will be a git master build, and can just sit in edge, nothing for the release team to do. On new release: The next build triggered will contain the stable release, and will be published to edge. Someone on the release team can login to the above URL and release that again to stable & candidate. Alternatively they can release to candidate, do some additional testing on that release before releasing to stable. Hope that all makes sense. Questions / comments welcome. I'm super keen to see stable releases of Gitea in the stable channel of the Snap Store. I'd like to promote it but I can't really until it's in stable. Co-authored-by: techknowlogick <techknowlogick@gitea.io>
2020-07-18 01:27:00 +08:00
last_committed_tag="$(git for-each-ref --sort=taggerdate --format '%(tag)' refs/tags | tail -n 1)"
last_released_tag="$(snap info gitea | awk '$1 == "latest/candidate:" { print $2 }')"
# If the latest tag from the upstream project has not been released to
# stable, build that tag instead of master.
if [ "${last_committed_tag}" != "${last_released_tag}" ]; then
git fetch
git checkout "${last_committed_tag}"
fi
version="$(git describe --always | sed -e 's/-/+git/;y/-/./')"
[ -n "$(echo $version | grep "+git")" ] && grade=devel || grade=stable
snapcraftctl set-version "$version"
snapcraftctl set-grade "$grade"
override-build: |
set -x
TAGS="bindata sqlite sqlite_unlock_notify pam cert" make build
install -D gitea "${SNAPCRAFT_PART_INSTALL}/gitea"
cp -r options "${SNAPCRAFT_PART_INSTALL}/"
prime:
- -etc
- -usr/lib/systemd
- -usr/lib/gcc
- -usr/lib/sasl2
- -usr/lib/x86_64-linux-gnu/krb5
- -usr/share/apport
- -usr/share/bash-completion
- -usr/share/git-core/contrib
- -usr/share/man
- -usr/share/upstart
- -var