openSUSE:Build Service Concept GitUpstreamSupport

Open Build Service

End user - Packager - Development - Installations - Collaboration - Comparison

Overview

Many projects use git as scm of their choice. To create an easy and smooth workflow, osc and obs need support for git trees as resource for package sources.

Use cases

Current workflow

checkout/clone package, change and commit

osc:
osc co <prj> <pkg>
cd <prj>/<pkg>

git:
git clone <URL> <mypath>
cd <mypath>
work, branch, work, merge, commit, push
create <tarball>
mv <tarball> <prjdir> 

osc:
adapt specfile
osc build

git:
fix error
create <tarball>
mv <tarball> <prjdir>

osc:
osc adapt specfile
osc build
osc addremove
osc commit

This workflow needs many steps, is error-prone and take too much time.

Proposed workflow

Checkout/clone package, change and commit (with tarball upload)

osc git clone <obsPRJ> <obsPKG> <gitURL> <localpath> [<branch2track>/defaultbranch:osc]

• checks out BS project
• cd <obsPRJ>/<obsPKG>
• clone git repository to <localpath>
• write _git_repo metafile with:
  • git_url=<gitURL>
  • git_path=<localpath>
  • git_branch=<branch2track>
  • git_diff_head=FETCH_HEAD (=latest revision cloned from server)
  • git_revision=<sha1> (=revision # used in tree)

cd <localpath>
normal work in git repository - no tarball creation needed
cd ..

One goal is to keep current git-workflows and not to wrap/interfere with git.

osc git refresh

• generate patches from changes against INDEX or HEAD or FETCH_HEAD (tbd)
• generate tar from INDEX or HEAD or FETCH_HEAD (tbd) and write git_revision !
• add patches to specfile

osc build
cd <localpath>
fix error
cd ..
osc git refresh
osc build
osc commit

This workflow is much easier and less error-prone.

Checkout/clone package, change and commit (with source service)

An extension of this workflow would make use of the source service and only commit a file with the revision number and the patches instead of a full tarball. The source service would fetch the given revision on the server and create a tarball. This would save upload bandwith, but has obviously disadvantages for local builds.

Fresh checkout of an existing Build Service package with _git_repo file (git plugin enabled)

osc co <obsPRJ> <obsPKG>

Detection of _git_repo triggers automatically:

  git clone <gitURL> <localpath>                  (gitURL and localpath as defined in _git_repo)
  cd localpath
  git checkout -b <branch2track> <git_revision>   (branch2track and git_revision as defined in _git_repo)
  patches found in the osc tree are applied on top of <git_revision>

Git branch <branch2track> is now in the same state as the committed version. Normal work inside the git tree. osc git refresh, osc build, osc commit as needed.

Add git repository features to existing Build Service package

Update an existing package to make use of a git repository.

osc co <obsPRJ> <obsPKG>

This is a normal checkout.

osc git clone <gitURL> <localpath> <branch2track>

• clone git repository to <localpath>
• write _git_repo metafile with:
  • git_url=<gitURL>
  • git_path=<localpath>
  • git_branch=<branch2track>
  • git_diff_head=FETCH_HEAD (=latest revision cloned from server)
  • git_revision=<sha1> (=revision # used in tree)

TBD: handling of existing patches/tarballs ! For now:

• The "Source:"-tag is used for the git-tarball
• No "foreign"/non-git patches are allowed

Other workflows

Different git branches for varying Build Service packages

The definition git_branch in the _git_repo-file of every package makes it possible to track multiple branches of the same git tree for different packages.

E.g. branch bash-stable is used in the package Base:System/bash and branch bash-unstable is used in package Devel:Incubating/bash.