A sample repo to showcase a modern Software Development Lifecycle approach.
This demo showcases RBv2 capabilities in the context of a project
There is a different demo, tomjfrog/feniks
that showcases RBv2
capabilities without a project.
The automation featured in this repo was originally created from the JFrog CLI with the command: jf c export
. This
will create a base64 encoded string representing a pre-configured JPD from your local JF CLI installation.
Add the following as Repository Secrets in the Settings tab of the repository:
RELEASE_BUNDLE_SIGNING_KEY
: The name of the GPG Key to use for signing release bundles. This name is created when adding a GPG Key to Artifactory viaPlatform Security -> Keys Management -> Signing Keys
. NOTE: This is not the same as a GPG Key that's added via the REST API for RBv1 Distribution purposes.
Add the following as Repository Variables in the Settings tab of the repository:
- JF_BASE_URL: The base
JF_INSTANCE_NAME
The name of the JFrog instance to use for the environment. This is the name of the server created when executingjf c add <server id>
from the JFrog CLI.JF_PROJECT_KEY
: This demo features the RBv2 capabilities in the context of a project. This variable should be set to the Project key for a given project in Artifactory.JF_RELEASE_BUNDLE_NAME
: Arbitrary name that will be used as the name of the RBv2.JF_VIRTUAL_REPO
: The virtual repo that contains thedev-local
local repo and the Remote Proxy needed to build and publish the initial artifact and Maven build.
By committing to main
, whether via a direct push or a pull request, the build
workflow will be triggered. This
workflow will build the artifact and publish it to the target repository in Artifactory. For this demo, it's recommended
to set a virtual repo that holds a local and remote repository. This will allow the build to be published to the
local by default.
To build an RBv2, create a release in Github with the pattern x.{x}.{x}-rc-{y}
. Examples of valid tags to trigger
this workflow are 1.0.0-rc-1
or 1.0.0-rc-2
. This will execute the following steps workflow which will:
- Create an RBv2 from the latest published build.
- Promote that RBv2 to a specified QA repo.
This RBv2 could be distributed to Edge nodes for in-depth QA testing, which would likely be done with at least some manual workflows.
To build a SemVer release, create a release in Github with the pattern vx.{x}.{x}
. This will trigger a workflow to
promote the latest RBv2 to a Production repository and distribute it to an Edge node. The distribution will also do
a path mapping to the Edge node, thus copying the artifacts to a sensical path on the Edge node.
2