action-ebuild-release
Automatically create an ebuild from a template and deploy it to a repository whenever a new package is released.
Functionality
Once configured creating a release will trigger the workflow and automatically:
- create a new ebuild for the released version
- calculate best possible
KEYWORDS
, if required - fetch package archives
- regenerate manifest files
- perform QA tests using repoman
- deploy to an overlay repository
- create / update a pull request
Automatic pre-release testing can be easily included using action-ebuild-test.
Basic Use
.gentoo
folder in the root of your repository.
1. Create a 2. Create a live ebuild template in the appropriate sub-directory.
.gentoo/dev-libs/hacking-bash-lib/hacking-bash-lib-9999.ebuild
# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
DESCRIPTION="A library script to log output and manage the generated log files"
HOMEPAGE="https://github.com/GITHUB_REPOSITORY"
LICENSE="LGPL-3"
if [[ ${PV} = *9999* ]]; then
inherit git-r3
EGIT_REPO_URI="https://github.com/GITHUB_REPOSITORY"
EGIT_BRANCH="GITHUB_REF"
else
SRC_URI="https://github.com/GITHUB_REPOSITORY/archive/${PV}.tar.gz -> ${P}.tar.gz"
fi
KEYWORDS=""
IUSE="test"
SLOT="0"
RESTRICT="!test? ( test )"
RDEPEND="app-arch/bzip2
mail-client/mutt
sys-apps/util-linux"
DEPEND="test? (
${RDEPEND}
dev-util/bats-assert
dev-util/bats-file
)"
src_test() {
bats --tap tests || die "Tests failed"
}
src_install() {
einstalldocs
insinto /usr/lib
doins usr/lib/*
}
The special markers GITHUB_REPOSITORY
and GITHUB_REF
will be automatically replaced with appropriate values
when the action is executed.
If you use an empty KEYWORDS
variable then the best possible keywords, based on the keywords of all dependencies,
will be used. NOTE: If no dependencies are specified then an empty KEYWORDS
variable will result in an empty
KEYWORDS
variable being used in the final ebuild.
3. Create a metadata.xml file
.gentoo/dev-libs/hacking-bash-lib/metadata.xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="person">
<email>overlay-maintainer@example.com</email>
<name>Overlay Maintainer</name>
</maintainer>
<upstream>
<maintainer>
<email>default-package-maintainer@example.com</email>
<name>Default Package Maintainer</name>
</maintainer>
<bugs-to>https://github.com/MADhacking/bash-outlogger/issues</bugs-to>
<doc>https://github.com/MADhacking/bash-outlogger</doc>
</upstream>
</pkgmetadata>
4. Create a GitHub workflow file
.github/workflows/release-package.yml
name: Release Package
on:
release:
types: [published, edited]
jobs:
tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- uses: hacking-gentoo/action-ebuild-release@v1
with:
auth_token: ${{ secrets.PR_TOKEN }}
deploy_key: ${{ secrets.DEPLOY_KEY }}
overlay_repo: hacking-gentoo/overlay
5. Create tokens / keys for automatic deployment
PR_TOKEN
Configuring The above workflow requires a personal access token be configured for the user running the release action.
This access token will need to be made available to the workflow using the secrets feature and will be used to authenticate when creating a new pull request.
DEPLOY_KEY
Configuring The above workflow also requires a deploy key be configured for the destination repository.
This deploy key will also need to be made available to the workflow using the secrets feature.