Automatically create an ebuild from a template and deploy it to a repository whenever a new package is released.
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.
.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.
.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>[email protected]</email>
<name>Overlay Maintainer</name>
</maintainer>
<upstream>
<maintainer>
<email>[email protected]</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>
.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
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.
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.