#323 Scratch builds on pull requests
Closed 7 years ago Opened 7 years ago by dhodovsk.

We would like to be able to trigger automated scratch builds in OSBS on pagure pull requests, but we are blocked. It seems that rhpkg won't allow builds on repositories that have detached state.

Steps to reproduce:
1, clone pagure repo
git clone ssh://git@git.src-stage.osci.redhat.com:32102/rpms/rh-mariadb102-docker --branch rhscl-3.2-rh-mariadb102-rhel-7

2, fetch and checkout pull request
git fetch origin refs/pull/2/head
git checkout FETCH_HEAD

3, trigger build
rhpkg --path /home/scratch-build-bot/rh-mariadb102-docker container-build --scratch --signing-intent unsigned --target rhscl-3.2-rh-mariadb102-rhel-7

Expected state:
- the build is triggered on commits added by pull request.

Actual state:
- Fails with Could not execute container_build: Repo in inconsistent state: HEAD is a detached symbolic reference as it points to 'cba63c3bfc1e6213ed38f63d58bec057dc47fe98'


If a repo is in detached, rpkg cannot get the branch name and that is what a detached repo behaves. Is there any way to apply the pull request patch to avoid the repo is detached? You could also have a try with option --release.

I was told that --release is deprecated and --target should be used instead, is that information correct? Also when running it with --release tag:
$ rhpkg --path /home/scratch-build-bot/rh-mariadb102-docker container-build --scratch --signing-intent unsigned --release rhscl-3.2-rh-mariadb102-rhel-7

it returns rhpkg: error: unrecognized arguments: --release rhscl-3.2-rh-mariadb102-rhel-7

The --release option has to be specified directly after rhpkg, it's a global option and argparse is pedantic about the order.

--release is not deprecated. The same option was originally called --dist, and that name is deprecated.

Rhpkg guesses a lot of information based on current git branch. When using --release, it basically tells it what branch you are on. So using --release=foo is the same as working on branch foo.

The --target option tells pungi not to guess the build target, but instead use the provided value.

The full workflow for determining build target is:

  1. If --target is given, use that value
  2. If --release (or deprecated --dist) is given, guess target based on the given branch
  3. Otherwise read current branch and guess based on that

@dhodovsk Does it work for you now?

No response from reporter for several days. Please refer to suggestion in above comments. Feel free to keep discussion if there is still other thoughts on this issue.

Metadata Update from @cqi:
- Issue status updated to: Closed (was: Open)

7 years ago

Log in to comment on this ticket.

Metadata