Nemo/Development

Automated Packaging from git

Setting up a webhook to github

Open the git tree you have. Go to Settings->Service Hooks->WebHook URLs (Guide at Github)and enter https://webhook.merproject.org/webhook/ to the URL field. Click "Update Settings" and "Test Hook".

NOTE: If you don't see the "Settings" tab as shown here, contact your project admin to give you more rights.

After clicking "Test Hook" the webhooks admin interface will show to the admins that you have active git tree. Now contact on the admins Sage or w00t at #nemomobile IRC channel and they will help you to setup the rest of the webhook process. Here the admin asks you what will be the package name and the target obs project where it should go and saves the information to the webhook admin interface. After this you can check the that the information is valid from https://webhook.merproject.org/webhook/

With tar_git service

tar_git is the service that is used to package packages where nemomobile is the upstream, which means packages that are located at https://github.com/nemomobile/

File structure

With tar_git service packaging information is carried on the same git branch with the code in rpm/ subdirectory. This directory can contain any files which all are exported to packaging in OBS. Usually the content is just plain spec file:

rpm/
  example.spec

If more than one .spec, .yaml or .changes is present the one that matches to the "Package" in webhooks will be taken. This allows one to create multiple packages with same source and different .spec file.

Changelogs

Changelogs are automatically generated from git commit messages, when ever git commit contains line that contains the following format

[sample text] Longer sample text
[feature] New feature X added

it is added automatically to the next changelog entry when new version is tagged. NOTE: Also should be noted that there MUST be at least one commit between each tag that contains a line shown above so that the changelog will be generated properly. Here is example how the lines above would correspond in .changes file

* Mon Apr 08 2013 Developer <developer@developer.dev> - 0.1
- [sample text] Longer sample text
- [feature] New feature X added

NOTE: If you have existing changelog that isn't already in proper format, i.e., git tags and commit messages, you need to add the old .changes file to the rpm/ directory. This .changes file will be is used as a base of the changelog generation and automated changelogs are appended to that. Should be noted that this changes file MUST NOT be updated after adding it to the git tree.

Tagging

When ever you do tag on the branch enabled with the webhook, it will automatically launch the tar_git service and the new sources will be downloaded and built on the target project.

Please refer to the tagging format at: https://wiki.merproject.org/wiki/Nemo/Development/Releasing

Logs/Process

To follow the behaviour of your webhooks you can join to #mer-boss IRC channel @ Freenode. Here is couple of examples of those messages:

< Merbot`> Tag(s) by Developer X in master branch of https://github.com/nemomobile/nemo-qml-plugins.git, which will trigger build in project nemo:devel:mw package nemo-qml-plugins (https://build.merproject.org//package/show?package=nemo-qml-plugins&project=nemo:devel:mw)
< Merbot`> 1 commit(s) pushed by Developer Y to master branch of https://github.com/tswindell/telepathy-ring.git

If you tagged a package you can click the link and check that everything is ok.

Testing rpm package build before committing

To test sources that have tar_git packaging there is tool called mb, this can be installed to Mer Platform SDK and comes in package called sdk-utils. The usage is following:

mb build -t [sb2-target] rpm/my-package.spec

This automatically downloads and installs the dependencies to the sb2 target you specified and then builds and rpm package from the sources within that sb2 target.

After this you can move the rpm to the target device and install it and test that everything is ok. The rpm filename can be seen in the end of mb command if it was successfull. Example below.

...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/sage/rpmbuild/BUILDROOT/nemo-mobile-session-13-0.arm
Wrote: /home/sage/rpmbuild/RPMS/armv7hl/nemo-mobile-session-13-0.armv7hl.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.YyhUi6
+ umask 022
+ cd /home/sage/rpmbuild/BUILD
+ cd nemo-mobile-session
+ /bin/rm -rf /home/sage/rpmbuild/BUILDROOT/nemo-mobile-session-13-0.arm
+ exit 0

In case you are building dependency packages and need them for sb2 target you can also install it to your target easily

sb2 -t mer-core -R -m sdk-install rpm -Uvh --force /home/sage/rpmbuild/RPMS/armv7hl/nemo-mobile-session-13-0.armv7hl.rpm

FAQ

Q: I removed a tag remotely and pushed it again, but this didn't trigger the webhook at github?
A: Retag locally and then push again.

With git_pkg service

For packages where Nemo isn't upstream there is plan to use git_pkg instead of tar_git. See https://github.com/lbt/git-pkg for the code. This integration work has not started yet.

Before starting to use git_pkg you need to set following environment variables if using gitpkg <= 0.0.5

export EDITOR=vim
export GIT_AUTHOR_NAME="Developer"
export GIT_AUTHOR_EMAIL="developer@my-dev.dev"

Structure

With gitpkg there is the master branch which contains the code, but only the code and no packaging information. The packaging information is located in separate pkg-mer branch.

Create new release

Before doing release you need to tag the version in master branch, e.g.,

git tag 0.26

After this you can do the release

gp_release --ver=0.26

After calling this command EDITOR is opened and you are asked to fill in the changelog information.

FAQ

Q: I screwed up something when doing gp_release --ver=0.1.1 how can I revert?

A:

git tag -d pkg-mer-0.1.1-1 mer-0.1.1-1;
git checkout pkg-mer && git reset --hard HEAD~1 && git checkout master;

Other stuff

This section is a bit of a guide about how to perform unified development on the software that we (in Nemo) write and maintain.

• Nemo/Development/Releasing - for releasing software we maintain