OBS Minor Release HOWTO

Table of Contents

• How do we do minor releases?
  • How to test the latest release?
  • Issue Handling
  • Fix it!
  • Issue fixed. What’s next?
    • Update obs-server package in Staging
    • Change version in the appliance for Staging
    • Test the new release with openQA
    • Test the new release manually (optional as it is already done in the openQA tests)
  • Let's release!
    • Release the packages
    • Announcement
    • Tag the released code
  • Troubleshooting

How do we do minor releases?

This is a documentation about updating OBS from X.Y.Z to X.Y.(Z+1) (so let's say from 2.8.0 to 2.8.1).

For the rest of this document:

• $VERSION: refers to 2.8
• $NEW_MINOR_VERSION: refers to 2.8.1

The main reason to publish a new minor release is to fix some security bug, sometimes reported internally by the security team. Check the issue handling procedure.

The first step is trying to reproduce the error in the code we maintain: master and the latest release which is X.Y.Z (e.g. 2.10.8). The possible scenarios are:

Reproducible on master	Reproducible on the latest release	What should you do?
Yes	Yes	Try to find a solution for both master and the latest released version of the code.
Yes	No	It can be a "regression", open an issue on GitHub, its priority will probably increase.
No	Yes	Try to find what solved the problem on master, try to apply a similar solution to the latest release.
No	No	Inform that the user is probably running a no longer maintained version of the code.

How to test the latest release?

Download the most recent appliance from Open Build Service and run it in a Virtual Machine. The OBS Apliance guide can help you.

Issue Handling

If the issue, usually reported via Bugzilla, is reproducible in the latest release and we consider that should be fixed in the appliance, then we have to publish a new minor release.

Before that, we have to ask the security team to allocate a new CVE number for us. This is an example of an existing CVE. The new CVE should be mentioned in the release notes of the new version.

Fix it!

Once you know what the problem is, collect patches for the new release. You have to open a Pull Request with the changes towards the correct branch. For example, if the latest release is X.Y.Z (e.g. 2.8.0), the corresponding branch is X.Y (e.g. 2.8).

1. Commit the changes to the corresponding git version branch.
2. Add a ReleaseNotes-$NEW_MINOR_VERSION file in the root of the git repository.
3. In the release notes file, mention any important change / bug fix made since the last release. Also mention the newly allocated CVE number if any.

The PR should pass all the CI tests, but the code should also pass the OpenQA tests. This guide can help you to run OpenQA smoke tests locally.

Issue fixed. What's next?

You found a solution, your PR was merged and all sort of tests passed. The next step is to update obs-server package inside OBS:Server:X.Y:Staging (e.g. OBS:Server:2.8:Staging) and see if it still builds for all the distributions. Follow the next steps to do so:

Update obs-server package in Staging

1. Check out the obs-server package OBS:Server:$VERSION:Staging and move into its directory:

   osc co OBS:Server:$VERSION:Staging obs-server
   cd OBS:Server:$VERSION:Staging/obs-server

2. Change the version inside the _service file to $NEW_MINOR_VERSION (e.g. 2.8.1). Leave the revision value as the branch name (e.g. 2.8):

   <service name="obs_scm">
     <param name="version">$NEW_MINOR_VERSION</param>
     <param name="revision">2.8</param>
     ...
   </service>

3. Run osc vc obs-server.changes and paste the ReleaseNotes-$NEW_MINOR_VERSION file.

4. Run osc ci so OBS:Server:$VERSION:Staging / obs-server will start building again.

5. Watch the package obs-server to succeed for all distributions.

Change version in the appliance for Staging

1. Inside the package OBS:Server:$VERSION:Staging/OBS-Appliance, edit the file OBS-Appliance.kiwi (you can do it via WebUI). There, set all the version tags to $NEW_MINOR_VERSION:

   <version>$NEW_MINOR_VERSION</version>
   ...
   <version>$NEW_MINOR_VERSION</version>
   

2. Watch the package OBS-Appliance to succeed for all distributions.

Test the new release with openQA

The newly created OBS:Server:$VERSION:Staging appliances are automatically tested by openQA. Make sure the tests succeed!

You can also check that the new version appears on http://download.opensuse.org/repositories/OBS:/Server:/$VERSION:/Staging/images/.

Test the new release manually (optional as it is already done in the openQA tests)

1. osc co OBS-Appliance-vmdk
   • (If you use VirtualBox, use vdi format from OBS 2.7 on!)
2. osc getbinaries images
3. Start the .vmdk / .vdi file in Virtual box:
   • NOTE: if you use VirtualBox remember to configure your network as Bridged Adapter.
   • Test that apache & buildservice starts automatically.
   • Test your changes work and have not introduced any regression:
     • Create an Interconnect to openSUSE.org.
     • Create the Admin:home project.
     • Branch from Interconnect openSUSE.org:openSUSE:Tools/build package.
     • Add build targets to the project and watch package build.

Let's release!

Release the packages

All steps so far only affect Staging. Before you move forward, ensure that all the tests passed and all the builds succeded. Now you are about to really publish the new minor release.

Release the staging project with:

osc release --no-delay OBS:Server:$VERSION:Staging

This command simply copies all the sources and binaries from OBS:Server:$VERSION:Staging to OBS:Server:$VERSION. That behaviour is specified in the releasetarget tag inside the meta file of OBS:Server:$VERSION:Staging. Example:

<repository name="openSUSE_15.2">
    <releasetarget project="OBS:Server:2.10" repository="openSUSE_15.2" trigger="manual"/>
    ...
</repository>

The --no-delay option will make the command to run immediately the release, and wait for a result. Otherwise there is no way to know if it has finished or didn't start yet.

Wait until the Staging project gets released. You can check that the new version appears on http://download.opensuse.org/repositories/OBS:/Server:/$VERSION/images/.

Announcement

Write a mail like this to our public mailing list.

Tag the released code

git fetch upstream
git checkout upstream/$VERSION
git tag -a $NEW_MINOR_VERSION
git push upstream $NEW_MINOR_VERSION

Troubleshooting

In the past, we had some problems when we used the same name for a git branch and for a git tag. To avoid conflicts, ensure you never create tags with the format X.Y (for example 2.10), they are reserved for branches. The tags should always look like X.Y.Z. Summarizing:

• branch 2.10: OK.
• tag 2.10: WRONG!
• tag 2.10.0: OK.