Skip to content

Commit aba12dd

Browse files
committed
8.5 release
1 parent a1c7d7d commit aba12dd

File tree

2 files changed

+3
-3
lines changed

2 files changed

+3
-3
lines changed

Dockerfile

+1-1
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ LABEL maintainer="Robert Scheck <https://github.com/openbgpd-portable/openbgpd-c
3131
org.label-schema.usage="https://man.openbsd.org/bgpd" \
3232
org.label-schema.vcs-url="https://github.com/openbgpd-portable"
3333

34-
ARG VERSION=8.4
34+
ARG VERSION=8.5
3535
ARG PORTABLE_GIT
3636
ARG PORTABLE_COMMIT
3737
ARG OPENBSD_GIT

README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -53,7 +53,7 @@ While none of the volumes is required, meaningful usage requires at least a prop
5353

5454
For custom OCI images, the following build arguments can be passed:
5555

56-
* `VERSION` - Version of the signed portability shim release tarball, defaults to `8.4`.
56+
* `VERSION` - Version of the signed portability shim release tarball, defaults to `8.5`.
5757
* `PORTABLE_GIT` - Git repository URL of the portability shim, defaults to `https://github.com/openbgpd-portable/openbgpd-portable.git`.
5858
* `PORTABLE_COMMIT` - Git commit, branch or tag of the portability shim, e.g. `master`, unset by default.
5959
* `OPENBSD_GIT` - Git repository URL of the OpenBSD source code, defaults to `https://github.com/openbgpd-portable/openbgpd-openbsd.git`.
@@ -67,7 +67,7 @@ To build a custom OCI image from current Git, e.g. `--build-arg PORTABLE_COMMIT=
6767

6868
Thus the OCI images are effectively built within the GitHub infrastructure (using [free minutes](https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions) for public repositories) and then only pushed to both container repositories, Docker Hub and Quay (which are also free for public repositories). This not only saves repeated CPU resources but also ensures identical bugs independent from which container repository the OCI image gets finally pulled (and somehow tries to keep it distant from program changes such as [Docker Hub Rate Limiting](https://www.docker.com/increase-rate-limits) in 2020). The authentication for the pushes to the container repositories happen using access tokens, which at Docker Hub need to be bound to a (community) user and at Quay using a robot account as part of the organization. These access tokens are saved as "repository secrets" as part of the settings of the GitHub project.
6969

70-
For each release of the project, a new Git branch (named like the version of the release, e.g. `8.4`) is created (based on the default branch, e.g. `master`). The workflow takes care about creating and moving container tags, such as `latest`. By not using Git tags but branches, downstream bug fixes can be easily applied to the OCI image (e.g. for bugs in the `Dockerfile` or patches for the source code itself). Old branches are not touched anymore, equivalent to old release archives.
70+
For each release of the project, a new Git branch (named like the version of the release, e.g. `8.5`) is created (based on the default branch, e.g. `master`). The workflow takes care about creating and moving container tags, such as `latest`. By not using Git tags but branches, downstream bug fixes can be easily applied to the OCI image (e.g. for bugs in the `Dockerfile` or patches for the source code itself). Old branches are not touched anymore, equivalent to old release archives.
7171

7272
Each commit to a Git branch triggers the workflow and leads to OCI images being pushed (except for GitHub pull requests), where the container tag is always based on the Git branch name. OCI images with non-release container tags pushed for testing purposes need to be cleaned up manually at the container repositories. Additionally, a cron-like option in the workflow leads to a nightly build being also tagged as `edge`.
7373

0 commit comments

Comments
 (0)