obmc-gerrit: Return empty list on missing MAINTAINERS

Prevents dumping a traceback when no MAINTAINERS is present:

  $ obmc-gerrit push gerrit HEAD:refs/for/master
  Traceback (most recent call last):
    File "/home/andrew/.local/bin/obmc-gerrit", line 63, in <module>
      args.func(args)
    File "/home/andrew/.local/bin/obmc-gerrit", line 51, in do_push
      git.push(args.remote, decorate_refspec(args.refspec),
    File "/home/andrew/.local/bin/obmc-gerrit", line 45, in decorate_refspec
      gargs = gerrit_refspec_args(get_reviewers())
    File "/home/andrew/.local/bin/obmc-gerrit", line 24, in get_reviewers
      with open(mfile, 'r') as mstream:
  FileNotFoundError: [Errno 2] No such file or directory: '/home/andrew/src/openbmc/phosphor-mboxd/MAINTAINERS'

Also, avoid mangling the refspec if the set of reviewers is empty -
there's no need for the trailing '%':

  $ obmc-gerrit push ph-gerrit HEAD:refs/for/master
  ...
  To ssh://gerrit.openbmc-project.xyz:29418/openbmc/phosphor-mboxd
   * [new branch]                HEAD -> refs/for/master%

Change-Id: I35300149f61089d4325532c45329e0fb4df6c009
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
1 file changed
tree: bd6e4e9e44f5fd31553413d00691ea10e0e829c9
  1. amboar/
  2. emilyshaffer/
  3. geissonator/
  4. infra/
  5. leiyu/
  6. post-process/
  7. thalerj/
  8. LICENSE
  9. README.md
README.md

The OpenBMC Tools Collection

The goal of this repository is to collect the two-minute hacks you write to automate interactions with OpenBMC systems.

It's highly likely the scripts don't meet your needs - they could be undocumented, dysfunctional, utterly broken, or sometimes casually rm -rf ~. Don't even think about looking for tests.

Repository Rules

  • Always inspect what you will be executing
  • Some hacking on your part is to be expected

You have been warned.

If you're still with us

Then this repository aims to be the default destination for your otherwise un-homed scripts. As such we are setting the bar for submission pretty low, and we aim to make the process as easy as possible:

Sending patches

However you want to send patches, we will probably cope:

What we will do once we have your patches

Look, the rm -rf ~ thing was a joke, we will be keeping an eye on all of you for such shenanigans. But so long as your patches look sane with a cursory glance you can expect them to be applied. To be honest, even Perl will be considered moderately sane.

What you must have in your patches

We don't ask for much, but you need to give us at least a Signed-off-by, and put your work under the Apache 2.0 license. Licensing everything under Apache 2.0 will just hurt our heads less. Lets keep the lawyers off our backs. ^

^ Any exceptions must be accompanied by a LICENSE file in the relevant subdirectory, and be compatible with Apache 2.0. You thought you would get away without any fine print?

How you consume the repository

Probably with difficulty. Don't expect the layout to remain static, or scripts to continue to exist from one commit to the next.