Add a note about creating a release branch
This content is taken from the Wiki[0] and updated to match the current state of the kitchen. [0] https://wiki.openstack.org/wiki/OpenstackChefStablebranchCreateNotes Change-Id: Iea9b41b99003cab37467e0c786a2b7e5e490c7a6 Signed-off-by: Lance Albertson <lance@osuosl.org>
This commit is contained in:
parent
8cb61b9a61
commit
6535c3427e
142
doc/source/contributor/create-stable-branch.rst
Normal file
142
doc/source/contributor/create-stable-branch.rst
Normal file
@ -0,0 +1,142 @@
|
|||||||
|
Steps to create a stable release branch
|
||||||
|
=======================================
|
||||||
|
|
||||||
|
Awesome! We've decided as a group to create the next stable branch. Here
|
||||||
|
are some steps to remind you on how to do it.
|
||||||
|
|
||||||
|
#. Go to `each repo`_ as a core member and create the branch with the
|
||||||
|
SHA you want, usually you will just branch from master.::
|
||||||
|
|
||||||
|
git checkout master
|
||||||
|
git pull
|
||||||
|
git checkout -b stable/<release>
|
||||||
|
git push gerrit stable/<release>
|
||||||
|
|
||||||
|
#. Changes for each cookbook and repo, create a bug to tie all the
|
||||||
|
following branch work together
|
||||||
|
|
||||||
|
a. Update ``.gitreview`` to include ``defaultbranch=stable/<release>``
|
||||||
|
|
||||||
|
b. Update ``Berksfile`` to reference ``branch: 'stable/<release>'`` for each branched cookbook
|
||||||
|
|
||||||
|
c. See https://review.opendev.org/729795 for an example
|
||||||
|
|
||||||
|
#. Create a review with the above and put it up against the ``stable/<release>`` branch.
|
||||||
|
|
||||||
|
#. Get it merged in and you should be good
|
||||||
|
|
||||||
|
.. _each repo: https://governance.openstack.org/tc/reference/projects/openstack-chef.html
|
||||||
|
|
||||||
|
If you think doing this manually for all the cookbooks is a lot of work,
|
||||||
|
these commands might help you automating it (please CHECK the git diff
|
||||||
|
before you actually push something):
|
||||||
|
|
||||||
|
#. First pull all the cookbooks into one folder and then try to run
|
||||||
|
these commands one by one from the root folder (they are
|
||||||
|
intentionally separated, since they will create some changes that you
|
||||||
|
do not want to push).
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
for i in -bare-metal -block-storage client -common -compute \
|
||||||
|
-dashboard -dns -identity -image -integration-test -network \
|
||||||
|
-ops-database -ops-messaging -orchestration -telemetry ; do
|
||||||
|
git clone https://opendev.org/openstack/cookbook-openstack${i}
|
||||||
|
done
|
||||||
|
|
||||||
|
#. Check your ``sed`` version and make sure you have at least version
|
||||||
|
4.2.1 (if you are on OS X you have to install ``gnu-sed`` via
|
||||||
|
Homebrew since the one installed does work in mysterious ways).
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
export RELEASE=train
|
||||||
|
for i in $(ls | grep cookbook) ; do
|
||||||
|
cd $i
|
||||||
|
git checkout -b stable/${RELEASE}
|
||||||
|
sed -i "/opendev/a\ \ branch: 'stable\/${RELEASE}'" Berksfile
|
||||||
|
sed -i 's/opendev.*$/&,/' Berksfile
|
||||||
|
echo "defaultbranch=stable/${RELEASE}" >> .gitreview
|
||||||
|
cd ..
|
||||||
|
done
|
||||||
|
|
||||||
|
# The next one is important, since there are changes that are wrong
|
||||||
|
# and should be corrected manually (like adding the branch:
|
||||||
|
# stable/train for a non-openstack cookbook)
|
||||||
|
for i in $(ls | grep cookbook) ; do cd $i; git diff; cd .. ; done | less
|
||||||
|
|
||||||
|
# After you checked all your changes, you can go ahead, commit it and
|
||||||
|
# push it up for review.
|
||||||
|
for i in $(ls | grep cookbook) ; do
|
||||||
|
cd $i
|
||||||
|
git review -s
|
||||||
|
git commit -am "stable/${RELEASE} release patch"
|
||||||
|
git review
|
||||||
|
cd ..
|
||||||
|
done
|
||||||
|
|
||||||
|
Steps for a new master branch
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
These steps are also useful when making global changes that are
|
||||||
|
dependent on each other.
|
||||||
|
|
||||||
|
Now we have a new master, need to get it in sync with matching base
|
||||||
|
OpenStack release.
|
||||||
|
|
||||||
|
#. Possible infra changes for changes to the gates we want for this
|
||||||
|
release.
|
||||||
|
|
||||||
|
#. Decide on new levels of tools (Chef Workstation, Cookstyle, upstream
|
||||||
|
cookbooks), we have always be trying to move forward with these.
|
||||||
|
|
||||||
|
#. Changes for each cookbook and repo:
|
||||||
|
|
||||||
|
a. Update metadata with new major version level
|
||||||
|
|
||||||
|
c. Run ``cookstyle -a`` to fix any style issues. Run Cookstyle again
|
||||||
|
and fix any issues that couldn't be fixed automatically.
|
||||||
|
|
||||||
|
d. Update code with refs to old OpenStack release, i.e. "ocata" ->
|
||||||
|
"pike" (Common release and yum attributes, ...).
|
||||||
|
|
||||||
|
e. Update all code looking for deprecation's that can now be removed.
|
||||||
|
|
||||||
|
f. Update any package dependencies that have changed for each
|
||||||
|
component.
|
||||||
|
|
||||||
|
g. Update all spec test platforms to targeted levels we want for this
|
||||||
|
release.
|
||||||
|
|
||||||
|
It will likely be necessary to disable integration jobs from being
|
||||||
|
voting on the ``openstack-chef`` repo in order to allow to merge all
|
||||||
|
these changes. If you do so, make sure that you have one patch at the
|
||||||
|
end which depends on all others, this one should be passing all
|
||||||
|
integration jobs again before you merge anything. See this `topic`_ as
|
||||||
|
an example.
|
||||||
|
|
||||||
|
.. _topic: https://review.opendev.org/#/q/topic:train-updates+(status:open+OR+status:merged)
|
||||||
|
|
||||||
|
You will want to do this in the following order and add ``Depends-On:``
|
||||||
|
to each review to it's dependencies. Everything should depend on the
|
||||||
|
openstack-chef repo since that's where all of the tests reside and will
|
||||||
|
need to be updated. To simplify, you can chain dependencies based on
|
||||||
|
their ``metadata.rb`` dependencies. See below on specifics:
|
||||||
|
|
||||||
|
#. openstack-chef Repo
|
||||||
|
#. Common (depends on openstack-chef)
|
||||||
|
#. Client (depends on openstack-chef and Common)
|
||||||
|
#. Ops-Messaging (depends on openstack-chef)
|
||||||
|
#. Ops-Database (depends on openstack-chef)
|
||||||
|
#. Identity (depends on Client, Ops-Messaging and Ops-Database)
|
||||||
|
#. Image (depends on Identity)
|
||||||
|
#. Block-Storage (depends on Image)
|
||||||
|
#. Network (depends on Identity)
|
||||||
|
#. Compute (depends on Image and Network)
|
||||||
|
#. Dns (depends on Network)
|
||||||
|
#. Orchestration (depends on Identity)
|
||||||
|
#. Telemetry (depends on Identity)
|
||||||
|
#. Dashboard (depends on Identity)
|
||||||
|
#. Integration-Test (depends on Image and Dns)
|
@ -10,3 +10,4 @@ Contributor Guide
|
|||||||
community
|
community
|
||||||
talk-to-us
|
talk-to-us
|
||||||
ci
|
ci
|
||||||
|
create-stable-branch
|
||||||
|
Loading…
Reference in New Issue
Block a user