Difference between revisions of "Fedora Koji Process"

From Dogtag
Jump to: navigation, search
(f28 branch)
m (f28 branch)
Line 714: Line 714:
 
   NOTE: In order to build pki-core-10.6.0-1.fc28, the proper versions of several previously built dependencies
 
   NOTE: In order to build pki-core-10.6.0-1.fc28, the proper versions of several previously built dependencies
 
         (e g. - jss, tomcatjss, nuxwdog) must exist in the 'f28-build' buildroot since 'pki-core' contains build
 
         (e g. - jss, tomcatjss, nuxwdog) must exist in the 'f28-build' buildroot since 'pki-core' contains build
         dependencies on these components. This can be checked using this command:
+
         dependencies on these components. This can be checked using this command:
  
 
         # koji latest-build f28-build jss tomcatjss nuxwdog
 
         # koji latest-build f28-build jss tomcatjss nuxwdog

Revision as of 01:08, 8 March 2018

Creating Dogtag PKI Packages on Fedora Koji

This example utilizes Fedora 28.

Verify that all Pagure Issues for a Given Milestone are Closed

Verify that all of Pagure issues for a <major>.<minor>.<patch> milestone have been closed and moved to that <major>.<minor>.<patch> milestone, or remain open in the <major>.<minor> backlog.

Edit the ~/.rpmmacros file in order to utilize the appropriate %{dist} value:

# vi ~/.rpmmacros

%dist .fc28

Checkout and Build from 'master' PKI Source Branch

    # dnf update
    
    # git clone git@github.com:dogtagpki/pki.git
    
    # script -c "USE_TIMESTAMP=0 USE_GIT_COMMIT_ID=0 pki/scripts/compose_dogtag_pki_meta_packages rpms" typescript.meta
    # mv packages packages.meta
    
    # script -c "USE_TIMESTAMP=0 USE_GIT_COMMIT_ID=0 pki/scripts/compose_dogtag_pki_theme_packages rpms" typescript.theme
    # cd packages/RPMS/noarch
    # sudo dnf install ./*.rpm
    # cd ../../..
    # mv packages packages.theme
    
    # script -c "USE_TIMESTAMP=0 USE_GIT_COMMIT_ID=0 pki/scripts/compose_pki_core_packages rpms" typescript.core
    # cd packages/RPMS
    # mkdir combined
    # cp -p */*.rpm combined
    # cd combined
    # rm *debug*.rpm pki-javadoc*.rpm
    # sudo dnf install ./*.rpm
    # cd ../../..
    # mv packages packages.core
    
    # script -c "USE_TIMESTAMP=0 USE_GIT_COMMIT_ID=0 pki/scripts/compose_pki_console_packages rpms" typescript.console
    # cd packages/RPMS/noarch
    # sudo dnf install ./*.rpm
    # cd ../../..
    # mv packages packages.console
    

Create Patches from the 'master' PKI Source Branch (Optional)

In the event that the build is going to utilize patches, rather than a new tarball, perform something similar to the following command:

    # git log
    # git format-patch <starting hash>^..<ending hash> --stdout > ../<component>-<version>-<patch name>.patch
      (e. g. - git format-patch d06bed84e50ac3acb578d4e0acc0a538e3826979^..c02268cc025ebfb0860d5528e080e208e09b3cbb --stdout > ../pki-core-10.6.0-pki-server-migration.patch
               git format-patch dfeb3c66d107123f173d58bf0a6571eb7fa3f260^..dfeb3c66d107123f173d58bf0a6571eb7fa3f260 --stdout > ../pki-core/10.6.0-link-zlib.patch)
    
      NOTE:  For this command, check-in hash ranges flow from earlier check-ins to later check-ins; undesired check-ins in the middle of such a range must be manually removed from the patch as necessary.
             Additionally, if a desired patch consists of a single check-in, then the starting and ending hashes are identical. 
    
    

Execute PKI Smoke Tests (Optional)

    • Optionally install a 389 DS Server.
    • Optionally pkispawn a CA, KRA, OCSP, TKS, and TPS and sanity test them.
    • Optionally test out PKI CLI.
    • Optionally test out PKI Console for CA, KRA, OCSP, and TKS.

Checkout fresh Koji branches

    # mkdir koji
    # cd koji
    # fedpkg clone -B dogtag-pki
    # fedpkg clone -B dogtag-pki-theme
    # fedpkg clone -B pki-core
    # fedpkg clone -B pki-console
    

Setup Local 'rpmbuild' Creation Repos

Download the 'compose' script

The following local 'rpmbuild' repos utilize the 'compose' script:

    #!/bin/bash
    #
    # Authors:
    #     Matthew Harmsen <mharmsen@redhat.com>
    #
    # --- BEGIN COPYRIGHT BLOCK ---
    # This program is free software; you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation; version 2 of the License.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License along
    # with this program; if not, write to the Free Software Foundation, Inc.,
    # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
    #
    # Copyright (C) 2016 Red Hat, Inc.
    # All rights reserved.
    # --- END COPYRIGHT BLOCK ---
    #
    
    SCRIPT=$0
    
    ######################
    ## Define Functions ##
    ######################
    
    usage() {
        echo
        echo "Usage:  $0 <name> <action> [-a arch] [-d dist] [-h]"
        echo
        echo "        where <action> must be one of the following:"
        echo
        echo "            dry-run  Print contents of variables"
        echo
        echo "            patch    Apply patches to the source tarball"
        echo
        echo "            srpm     Create a patched SRPM from source tarball + patches"
        echo
        echo "            rpms     Create patched RPMS from source tarball + patches"
        echo
        echo "            build    Create patched SRPM and RPMS from source tarball + patches"
        echo "                     (save build tree)"
        echo
        echo "            package  Create patched SRPM and RPMS from source tarball + patches"
        echo "                     (remove build tree)"
        echo
    }
    
    initialize() {
        rm -rf BUILD BUILDROOT RPMS SRPMS
    
        mkdir BUILD RPMS SRPMS
    }
    
    verify_prerequisite() {
        executable=$1
        rv=0
    
        command -v ${executable} >/dev/null 2>&1
        if [ $? -eq 1 ] ; then
            echo
            echo "The bash script \"${SCRIPT}\" requires \"${executable}\";"
            echo "please install the package which provides \"${executable}\"."
            echo
            rv=1
        fi
    
        return ${rv}
    }
    
    ###################################
    ## Verify Required Prerequisites ##
    ###################################
    
    PREREQUISITES=(date lsb_release pwd rpmbuild script)
    
    missing_prerequisites=0
    for prerequisite in "${PREREQUISITES[@]}" ; do
        verify_prerequisite ${prerequisite}
        missing_prerequisites=`expr ${missing_prerequisites} + $?`
    done
    
    if [ ${missing_prerequisites} -ne 0 ] ; then
        usage
        exit 255
    fi
    
    ######################
    ## Define Constants ##
    ######################
    
    ACTIONS=(dry-run patch srpm rpms build package)
    
    ARCHES=(aarch64 armv7hl i686 ppc ppc64 ppc64le s390 s390x x86_64)
    
    DISTRIBUTION=`lsb_release -is`
    
    OS_RELEASE=`lsb_release -rs`
    
    PWD=`pwd`
    
    TIMESTAMP=`date +%Y%m%d%H%M%S`
    
    #################################
    ## Test for Required Arguments ##
    #################################
    
    if [ $# -lt 1 ] ; then
        echo
        echo "Must specify a 'name'!"
        usage
        exit 255
    elif [ $# -lt 2 ] ; then
        echo
        echo "Must specify an 'action'!"
        usage
        exit 255
    fi
    
    ## Test for expected directory infrastructure
    missing_directories=0
    if [ ! -d "${PWD}/SOURCES/" ] ; then
        echo
        echo "The '${PWD}/SOURCES/' directory is missing!"
        echo
        missing_directories=`expr ${missing_directories} + 1`
    fi
    
    if [ ! -d "${PWD}/SPECS/" ] ; then
        echo
        echo "The '${PWD}/SPECS/' directory is missing!"
        echo
        missing_directories=`expr ${missing_directories} + 1`
    fi
    
    if [ ${missing_directories} -ne 0 ] ; then
        usage
        exit 255
    fi
    
    NAME=$1
    
    SPEC=${NAME}.spec
    
    ## Test for valid name
    if [ ! -f "${PWD}/SPECS/${SPEC}" ] ; then
        echo
        echo "The file '${PWD}/SPECS/${SPEC}' is missing!"
        usage
        exit 255
    fi
    
    ACTION=$2
    
    ## Test for valid action
    if ! [[ " ${ACTIONS[@]} " =~ " ${ACTION} " ]]; then
        echo
        echo "Invalid action '${ACTION}'!"
        usage
        exit 255
    fi
    
    TYPESCRIPT=${NAME}-${ACTION}.${TIMESTAMP}
    
    ##################
    ## Set Defaults ##
    ##################
    
    ## Defaults to the architecture of your current machine
    ARCH=`uname -m`
    
    ## Defaults to the distribution of your current machine
    ##
    ##     NOTE:  Double quotation marks '"' must surround values beginning
    ##            with '-' to prevent '=-' misinterpretation and to still
    ##            allow shell expansion of values which contain variables.
    ##
    if [ "${DISTRIBUTION:0:6}" == "CentOS" ] ; then
        DIST_RELEASE=${OS_RELEASE%.*}
        DIST=.el${DIST_RELEASE}.centos
        DIST_OPTION="-d ${DIST}"
        DIST_RPMBUILD_OPTION="--define \"dist ${DIST}\""
    elif [ "${DISTRIBUTION:0:6}" == "Fedora" ] ; then
        DIST=.fc${OS_RELEASE}
        DIST_OPTION="-d ${DIST}"
        DIST_RPMBUILD_OPTION="--define \"dist ${DIST}\""
    elif [ "${DISTRIBUTION:0:6}" == "RedHat" ] ; then
        DIST_RELEASE=${OS_RELEASE%.*}
        DIST=.el${DIST_RELEASE}
        DIST_OPTION="-d ${DIST}"
        DIST_RPMBUILD_OPTION="--define \"dist ${DIST}\""
    else
        DIST=
        DIST_OPTION=
        DIST_RPMBUILD_OPTION=
    fi
    
    #####################
    ## Parse Arguments ##
    #####################
    
    ## Process any remaining command-line options
    OPTIND=3
    while getopts "a:d:h" option; do
        case "${option}" in
            a)
                arch=${OPTARG}
                ## Test for supported architecture
                if [[ " ${ARCHES[@]} " =~ " ${arch} " ]]; then
                    ARCH=${arch}
                else
                    echo
                    echo "Unsupported architecture '${arch}'!"
                    usage
                    exit 255
                fi
                ;;
            d)
                DIST=${OPTARG}
                DIST_OPTION="-d ${DIST}"
                DIST_RPMBUILD_OPTION="--define \"dist ${DIST}\""
                ;;
            h)
                usage
                exit 0
                ;;
            *)
                usage
                exit 255
                ;;
        esac
    done
    shift $((OPTIND-1))
    
    ##################################
    ## Perform the specified action ##
    ##################################
    
    if [ "${ACTION}" == "dry-run" ] ; then
        ## Print contents of variables
        echo
        echo "COMMAND = '${SCRIPT} ${NAME} ${ACTION} -a ${ARCH} ${DIST_OPTION}'"
        echo
        echo "    ACTION        = '${ACTION}'"
        echo "    ACTIONS       = '(${ACTIONS[@]})'"
        echo "    ARCH          = '${ARCH}'"
        echo "    ARCHES        = '(${ARCHES[@]})'"
        echo "    DIST          = '${DIST}'"
        echo "    DISTRIBUTION  = '${DISTRIBUTION}'"
        echo "    NAME          = '${NAME}'"
        echo "    OS_RELEASE    = '${OS_RELEASE}'"
        echo "    PREREQUISITES = '(${PREREQUISITES[@]})'"
        echo "    SPEC          = '${SPEC}'"
        echo "    TIMESTAMP     = '${TIMESTAMP}'"
        echo "    TYPESCRIPT    = '${TYPESCRIPT}'"
        echo
    elif [ "${ACTION}" == "patch" ] ; then
        ## Apply patches to the source tarball
        initialize
        script -c "rpmbuild --define \"_topdir `pwd`\" ${DIST_RPMBUILD_OPTION} --target ${ARCH} -bp SPECS/${SPEC}" ${TYPESCRIPT}
    elif [ "${ACTION}" == "srpm" ] ; then
        ## Create a patched SRPM from source tarball + patches
        initialize
        script -c "rpmbuild --define \"_topdir `pwd`\" ${DIST_RPMBUILD_OPTION} --target ${ARCH} -bs SPECS/${SPEC}" ${TYPESCRIPT}
    elif [ "${ACTION}" == "rpms" ] ; then
        ## Create patched RPMS from source tarball + patches
        initialize
        script -c "rpmbuild --define \"_topdir `pwd`\" ${DIST_RPMBUILD_OPTION} --target ${ARCH} -bb SPECS/${SPEC}" ${TYPESCRIPT}
    elif [ "${ACTION}" == "build" ] ; then
        ## Create patched SRPM and RPMS from source tarball + patches
        ## (save build tree)
        initialize
        script -c "rpmbuild --define \"_topdir `pwd`\" ${DIST_RPMBUILD_OPTION} --target ${ARCH} -ba SPECS/${SPEC}" ${TYPESCRIPT}
    elif [ "${ACTION}" == "package" ] ; then
        ## Create patched SRPM and RPMS from source tarball + patches
        ## (remove build tree)
        initialize
        script -c "rpmbuild --define \"_topdir `pwd`\" ${DIST_RPMBUILD_OPTION} --target ${ARCH} -ba --clean SPECS/${SPEC}" ${TYPESCRIPT}
    fi
    

dogtag-pki

    # mkdir -p DOGTAG-PKI/archives
    # mkdir -p DOGTAG-PKI/SOURCES
    # mkdir -p DOGTAG-PKI/SPECS
    # cd DOGTAG-PKI/SOURCES
    # wget <latest successful Fedora 28 Koji build of the dogtag-pki SRPM>
    # rpm2cpio ./dogtag-pki*.rpm | cpio -idumv
    # mv ./dogtag-pki.spec ..
    # mv ./dogtag-pki*.rpm ../archives
    # cp -p <path to source checkout>/packages.meta/SRPMS/dogtag-pki*.rpm .
    # rpm2cpio ./dogtag-pki*.rpm | cpio -idumv
    # mv ./dogtag-pki.spec ../SPECS
    # rm ./dogtag-pki*.rpm
    # cd ..
    # diff dogtag-pki.spec <path to Koji>/koji/dogtag-pki/f28/dogtag-pki.spec
      (should be identical)
    
    Edit SPECS/dogtag-pki.spec making any changes necessary
    
    # diff dogtag-pki.spec SPECS/dogtag-pki.spec
    
    # compose dogtag-pki package -d .fc28
    

dogtag-pki-theme

    # mkdir -p DOGTAG-PKI-THEME/archives
    # mkdir -p DOGTAG-PKI-THEME/SOURCES
    # mkdir -p DOGTAG-PKI-THEME/SPECS
    # cd DOGTAG-PKI-THEME/SOURCES
    # wget <latest successful Fedora 28 Koji build of the dogtag-pki-theme SRPM>
    # rpm2cpio ./dogtag-pki-theme*.rpm | cpio -idumv
    # mv ./dogtag-pki-theme.spec ..
    # rm ./dogtag-pki-theme*.tar.gz
    # mv ./dogtag-pki-theme*.rpm ../archives
    # cp -p <path to source checkout>/packages.theme/SRPMS/dogtag-pki-theme*.rpm .
    # rpm2cpio ./dogtag-pki-theme*.rpm | cpio -idumv
    # mv ./dogtag-pki-theme.spec ../SPECS
    # rm ./dogtag-pki-theme*.rpm
    # cd ..
    # diff dogtag-pki-theme.spec <path to Koji>/koji/dogtag-pki-theme/f28/dogtag-pki-theme.spec
      (should be identical)
    
    Edit SPECS/dogtag-pki-theme.spec making any changes necessary
    (this is generally necessary when patches are utilized).
    
    # diff dogtag-pki-theme.spec SPECS/dogtag-pki-theme.spec
    # compose dogtag-pki-theme patch -d .fc28
    
    Fix any problems as necessary.
    
    Remember to check-in any non-patch changes
    (perhaps commented out patch logic to the
     'dogtag-pki-theme.spec' in the source repo)
    
    # compose dogtag-pki-theme package -d .fc28
    

pki-core

    # mkdir -p PKI-CORE/archives
    # mkdir -p PKI-CORE/SOURCES
    # mkdir -p PKI-CORE/SPECS
    # cd PKI-CORE/SOURCES
    # wget <latest successful Fedora 28 Koji build of the pki-core SRPM>
    # rpm2cpio ./pki-core*.rpm | cpio -idumv
    # mv ./pki-core.spec ..
    # rm ./pki-core*.tar.gz
    # mv ./pki-core*.rpm ../archives
    # cp -p <path to source checkout>/packages.core/SRPMS/pki-core*.rpm .
    # rpm2cpio ./pki-core*.rpm | cpio -idumv
    # mv ./pki-core.spec ../SPECS
    # rm ./pki-core*.rpm
    # cd .8
    # diff pki-core.spec <path to Koji>/koji/pki-core/f28/pki-core.spec
      (should be identical)
    
    Edit SPECS/pki-core.spec making any changes necessary
    (this is generally necessary when patches are utilized).
    
    # diff pki-core.spec SPECS/pki-core.spec
    # compose pki-core patch -d .fc28
    
    Fix any problems as necessary.
    
    Remember to check-in any non-patch changes
    (perhaps commented out patch logic to the
     'pki-core.spec' in the source repo)
    
    # compose pki-core package -d .fc28
    

pki-console

    # mkdir -p PKI-CONSOLE/archives
    # mkdir -p PKI-CONSOLE/SOURCES
    # mkdir -p PKI-CONSOLE/SPECS
    # cd PKI-CONSOLE/SOURCES
    # wget <latest successful Fedora 28 Koji build of the pki-console SRPM>
    # rpm2cpio ./pki-console*.rpm | cpio -idumv
    # mv ./pki-console.spec ..
    # rm ./pki-console*.tar.gz
    # mv ./pki-console*.rpm ../archives
    # cp -p <path to source checkout>/packages.console/SRPMS/pki-console*.rpm .
    # rpm2cpio ./pki-console*.rpm | cpio -idumv
    # mv ./pki-console.spec ../SPECS
    # rm ./pki-console*.rpm
    # cd ..
    # diff pki-console.spec <path to Koji>/koji/pki-console/f28/pki-console.spec
      (should be identical)
    
    Edit SPECS/pki-console.spec making any changes necessary
    (this is generally necessary when patches are utilized).
    
    # diff pki-console.spec SPECS/pki-console.spec
    # compose pki-console patch -d .fc28
    
    Fix any problems as necessary.
    
    Remember to check-in any non-patch changes
    (perhaps commented out patch logic to the
     'pki-console.spec' in the source repo)
    
    # compose pki-console package -d .fc28
    


Publish tarballs and patches to Upstream Openshift Repository

    # kinit
    # /usr/bin/ssh-add $HOME/.ssh/id_rsa_fedora
    

dogtag-pki

    NOTE:  Since the Dogtag PKI Meta package should never contain a tarball or any patches, there
           is no need to publish anything to the Openshift repository.
    

dogtag-pki-theme

    First Terminal:
      # oc rsh <pod> bash
      # export TERM=vt100
      # cd /opt/app-root/data/pki/sources
      # mkdir -p ./dogtag-pki-theme/10.6.0
      # cd app-root/data/pki/sources/dogtag-pki-theme/10.6.0
      # pwd
      /var/lib/openshift/<hash>/app-root/data/pki/sources/dogtag-pki-theme/10.6.0
      

    Second Terminal:

      Publish the tarball (and any patches) to the proper location in the OpenShift repository:
      # oc rsync . <pod>:/opt/app-root/data/pki/sources/dogtag-pki-theme/10.6.0 --exclude=* --include=dogtag-pki-theme-10.6.0.tar.gz --no-perms
      . . .
      

    Optionally perform a 'cksum' for each transferred file on both sides to verify that the transfer was successful.

pki-core

    First Terminal:
      # oc rsh <pod> bash
      # export TERM=vt100
      # cd /opt/app-root/data/pki/sources
      # mkdir -p ./pki-core/10.6.0
      # cd app-root/data/pki/sources/pki-core/10.6.0
      # pwd
      /var/lib/openshift/<hash>/app-root/data/pki/sources/pki-core/10.6.0
      

    Second Terminal:

      Publish the tarball (and any patches) to the proper location in the OpenShift repository:
      # oc rsync . <pod>:/opt/app-root/data/pki/sources/pki-core/10.6.0 --exclude=* --include=pki-core-10.6.0.tar.gz --no-perms
      . . .
      

    Optionally perform a 'cksum' for each transferred file on both sides to verify that the transfer was successful.

pki-console

    First Terminal:
      # oc rsh <pod> bash
      # export TERM=vt100
      # cd /opt/app-root/data/pki/sources
      # mkdir -p ./pki-console/10.6.0
      # cd app-root/data/pki/sources/pki-console/10.6.0
      # pwd
      /var/lib/openshift/<hash>/app-root/data/pki/sources/pki-console/10.6.0
      

    Second Terminal:

      Publish the tarball (and any patches) to the proper location in the OpenShift repository:
      # oc rsync . <pod>:/opt/app-root/data/pki/sources/pki-console/10.6.0 --exclude=* --include=pki-console-10.6.0.tar.gz --no-perms
      . . .
      

    Optionally perform a 'cksum' for each transferred file on both sides to verify that the transfer was successful.

Create External COPR Builds (Optional)

Create Koji Scratch Builds (Optional)

Create Official Koji Builds

dogtag-pki

    Verify that basically koji/dogtag-pki/f28 and koji/dogtag-pki/master are identical, otherwise, when constructing Fedora 28 builds below, one would need to construct Fedora 29 builds separately rather than merely using the same local SRPM for both koji/dogtag-pki/f28 AND koji/dogtag-pki/master!
    # diff koji/dogtag-pki/f28/dogtag-pki.spec koji/dogtag-pki/master/dogtag-pki.spec
      (if these are identical, then the same local SRPM may be utilized)
    
    f28 branch
    # cd koji/dogtag-pki/f28
    # fedpkg import <path to local rpmbuild repos>/DOGTAG-PKI/SRPMS/dogtag-pki*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    # bodhi updates new --type bugfix --request testing --stable-karma 3 --unstable-karma -3 --notes 'Resolves: dogtagpki Pagure Issue #<issue>,<issue>,...' $(fedpkg verrel)
    
    master branch
    # cd koji/dogtag-pki/master
    # fedpkg import <path to local rpmbuild repos>/DOGTAG-PKI/SRPMS/dogtag-pki*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    
    NOTE: The 'bodhi' step is not necessary for 'rawhide'.
    

dogtag-pki-theme

    Verify that basically koji/dogtag-pki-theme/f28 and koji/dogtag-pki-theme/master are identical, otherwise, when constructing Fedora 28 builds below, one would need to construct Fedora 29 builds separately rather than merely using the same local SRPM for both koji/dogtag-pki-theme/f28 AND koji/dogtag-pki-theme/master!
    # diff koji/dogtag-pki-theme/f28/dogtag-pki-theme.spec koji/dogtag-pki-theme/master/dogtag-pki-theme.spec
      (if these are identical, then the same local SRPM may be utilized)
    
    Be sure to verify that these builds contain the same patches as well!
    
    f28 branch
    # cd koji/dogtag-pki-theme/f28
    # fedpkg import <path to local rpmbuild repos>/DOGTAG-PKI-THEME/SRPMS/dogtag-pki-theme*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    # bodhi updates new --type bugfix --request testing --stable-karma 3 --unstable-karma -3 --notes 'Resolves: dogtagpki Pagure Issue #<issue>,<issue>,...' $(fedpkg verrel)
    
    master branch
    # cd koji/dogtag-pki-theme/master
    # fedpkg import <path to local rpmbuild repos>/DOGTAG-PKI-THEME/SRPMS/dogtag-pki-theme*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    
    NOTE: The 'bodhi' step is not necessary for 'rawhide'.
    


pki-core

    Verify that basically koji/pki-core/f28 and koji/pki-core/master are identical, otherwise, when constructing Fedora 28 builds below, one would need to construct Fedora 29 builds separately rather than merely using the same local SRPM for both koji/pki-core/f28 AND koji/pki-core/master!
    # diff koji/pki-core/f28/pki-core.spec koji/pki-core/master/pki-core.spec
      (if these are identical, then the same local SRPM may be utilized)
    
    Be sure to verify that these builds contain the same patches as well!
    
    f28 branch
    # cd koji/pki-core/f28
    
      NOTE: In order to build pki-core-10.6.0-1.fc28, the proper versions of several previously built dependencies
            (e g. - jss, tomcatjss, nuxwdog) must exist in the 'f28-build' buildroot since 'pki-core' contains build
            dependencies on these components. This can be checked using this command:
    
            # koji latest-build f28-build jss tomcatjss nuxwdog
            Build                                     Tag                   Built by
            ----------------------------------------  --------------------  ----------------
            jss-4.4.2-10.fc28                         f28                   releng
            tomcatjss-7.2.4-3.fc28                    f28                   releng
            nuxwdog-1.0.3-13.fc28                     f28                   mharmsen
    
      Use the following URL to override a package in the Koji build system:
        
        * https://bodhi.fedoraproject.org/overrides/new
          (IMPORTANT: No ending '/'!!!!)
        
        It will state to use the following:
        
        % koji wait-repo f28-build --build=tomcatjss-7.3.0-1.fc28
        
      If the override already exists but has EXPIRED, it will NOT let you add a NEW
      override.  To fix this, specify the problematic override and try the following:
        
        # https://bodhi.fedoraproject.org/overrides/tomcatjss-7.3.0-1.fc28
        
        It will show it expired; change the Expiration Date (and the notes)
        and re-submit.
        
        It will state to use the following:
    
        % koji wait-repo f28-build --build=tomcatjss-7.3.0-1.fc28
    
    # fedpkg import <path to local rpmbuild repos>/PKI-CORE/SRPMS/pki-core*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    # bodhi updates new --type bugfix --request testing --stable-karma 3 --unstable-karma -3 --notes 'Resolves: dogtagpki Pagure Issue #<issue>,<issue>,...' $(fedpkg verrel)
    
    master branch
    # cd koji/pki-core/master
    # fedpkg import <path to local rpmbuild repos>/PKI-CORE/SRPMS/pki-core*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    
    NOTE: The 'bodhi' step is not necessary for 'rawhide'.
    

pki-console

    Verify that basically koji/pki-console/f28 and koji/pki-console/master are identical, otherwise, when constructing Fedora 28 builds below, one would need to construct Fedora 29 builds separately rather than merely using the same local SRPM for both koji/pki-console/f28 AND koji/pki-console/master!
    # diff koji/pki-console/f28/pki-core.spec koji/pki-console/master/pki-console.spec
      (if these are identical, then the same local SRPM may be utilized)
    
    Be sure to verify that these builds contain the same patches as well!
    
    f28 branch
    # cd koji/pki-console/f28
    
      NOTE: In order to build pki-console-10.6.0-1.fc28, the previously built pki-core-10.6.0-1.fc28 must exist in
            the 'f28-build' buildroot since 'pki-console' contains the build dependency of  'pki-base-java >= 10.6.0'.
            While a previous release of pki-core 10.6.0 may already exist in the buildroot, it is usually a good idea
            to update the buildroot to the latest 10.6.0 release to be certain that 'pki-console' is married to the latest
            10.6.0 release of 'pki-base-java' to prevent any possible compilation issues.  
      
      Use the following URL to override a package in the Koji build system:
        
        * https://bodhi.fedoraproject.org/overrides/new
          (IMPORTANT: No ending '/'!!!!)
        
        It will state to use the following:
        
        % koji wait-repo f28-build --build=pki-core-10.6.0-1.fc28
        
      If the override already exists but has EXPIRED, it will NOT let you add a NEW
      override.  To fix this, specify the problematic override and try the following:
        
        # https://bodhi.fedoraproject.org/overrides/pki-core-10.6.0-1.fc28
        
        It will show it expired; change the Expiration Date (and the notes)
        and re-submit.
        
        It will state to use the following:
    
        % koji wait-repo f28-build --build=pki-core-10.6.0-1.fc28
        
    # fedpkg import <path to local rpmbuild repos>/PKI-CONSOLE/SRPMS/pki-console*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    # bodhi updates new --type bugfix --request testing --stable-karma 3 --unstable-karma -3 --notes 'Resolves: dogtagpki Pagure Issue #<issue>,<issue>,...' $(fedpkg verrel)
    
    master branch
    # cd koji/pki-console/master
    
      NOTE: In order to build pki-console-10.6.0-1.fc29, the previously built pki-core-10.6.0-1.fc29 must exist in
            the 'f29-build' buildroot since 'pki-console' contains the build dependency of  'pki-base-java >= 10.6.0'.
            While a previous release of pki-core 10.6.0 may already exist in the buildroot, it is usually a good idea
            to update the buildroot to the latest 10.6.0 release to be certain that 'pki-console' is married to the latest
            10.6.0 release of 'pki-base-java' to prevent any possible compilation issues.  
      
      For 'rawhide', only the following is required:
        
        % koji wait-repo f29-build --build=pki-core-10.6.0-1.fc29
        
    # fedpkg import <path to local rpmbuild repos>/PKI-CONSOLE/SRPMS/pki-console*.rpm
    # fedpkg clog (optional)
    # git add clog (optional)
    # git commit -a
      "Resolves: dogtagpki Pagure Issue #<issue>,<issue>,..."
      <changelog>
    # fedpkg push
    # fedpkg pull
    # fedpkg build
    
    NOTE: The 'bodhi' step is not necessary for 'rawhide'.
    

Mark 'fixedinversion' in all Pagure Issues for a Given Milestone (Optional)

For each Pagure issue for a <major>.<minor>.<patch> milestone that have been closed fixed, fill in the proper value(s) for the 'fixedinversion' field; use the lowest Fedora version of each component that needs to be specified.

For example, for Fedora 28 and Fedora 29, simply use the earliest Fedora component:

  • pki-core-10.6.0-1.fc28

Update and Check-in any changes to the 'master' PKI Source Branch (e. g. - spec file templates)

Create a Static Tag from the 'master' PKI Source Branch

At this stage, tag the original source repository, since it has produced official Fedora builds:

    # cd pki
    # git branch
    # git tag
    # git tag -a "v10.6.0" -m "Build for 10.6.0 for Fedora 28"
    # git show v10.6.0
    # git push origin v10.6.0
    

Document Resolved <major>.<minor>.<patch> Release Issues on the external Dogtag Wiki

Document the resolved issues at PKI Open Source History.

Specifically, there should be a Pagure Issue for each of these releases; unfortunately, this is one of the items that has fallen quite far behind; see the following:

dogtagpki Pagure Issue #2455 Dogtag 10.4.0 Release Tasks