meegointegration / boss-launcher-webhook Goto Github PK

Preconditions:

Place invalid or empty _service file to a webhook-mapped package in OBS. Trigger webhook.

Expected result:

Correct _service file is generated as if a new package would be created. A warning of an invalid XML is logged.

Actual result:

get_src_state participant of wh_trigger_build process failing with the following message:

raised: Ruote::Amqp::RemoteError: XMLSyntaxError: None

Traceback:

/usr/lib/python2.7/site-packages/RuoteAMQP/participant.py:84: in `run self.__participant.consume()'
/usr/lib/python2.7/site-packages/SkyNET/Exo.py:80: in `consume self.exo.handler.handle_wi(self.workitem)'
/usr/lib/python2.7/site-packages/boss/obs.py:88: in `wrapper return method(self, wid)'
/usr/share/boss-skynet/trigger_service.py:206: in `handle_wi services = etree.fromstring(services_xml)'
lxml.etree.pyx:2997: in `lxml.etree.fromstring (src/lxml/lxml.etree.c:63276) None'
parser.pxi:1617: in `lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:93691) None'
parser.pxi:1495: in `lxml.etree._parseDoc (src/lxml/lxml.etree.c:92490) None'
parser.pxi:1011: in `lxml.etree._BaseParser._parseDoc (src/lxml/lxml.etree.c:89130) None'
parser.pxi:577: in `lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:84831) None'
parser.pxi:676: in `lxml.etree._handleParseResult (src/lxml/lxml.etree.c:85936) None'
parser.pxi:627: in `lxml.etree._raiseParseError (src/lxml/lxml.etree.c:85428) None'

Add web hook mapping.
Fill "Repourl" as copy from browser(wtihout .git at the end), eg, from github.
Other fields does not matter.

Incoming webhook will be with .git at the end, so new created webhook would not be triggered.

Solution:
store repourl with .git at the end, add .git if doesn't ends with it.

I have an issue with checking out one of my packaging repositories: pkg-mapnik. It looks like something starts infinite loop when running:

bash tar_git --url https://github.com/rinigus/pkg-mapnik --debian N --dumb N --outdir TEST

Its always reproducible and prevents using this repo for OBS packaging.

The VCSCOMMIT_NOTIFY process allow to send messages to irc-channel, it accepts 'msg' as parameter and sends message to channel that is configured in the process file.

There is no way to send message to other channel if needed

Solution:
Accept "log_channel" as parameter and if it is not passed use default value.

We have several projects where we build the .spec file from some template via a script (usually called rpm/precheckin.sh, but I'm sure there are others) to account for slight differences (e.g. two packages for different device adaptations that differ only in package name and build flags, or multiple variations of the same package, etc..). This is good, but has several problems:

• We store generated files in the Git repository in addition to the template and the script
• People forget to run precheckin.sh and patch the generated (=output) files in Git, leading to problems down the line the next time the template is updated and precheckin.sh run (I've had this at least two times, and was on the "receiving end" of this issue, meaning I had to merge back changes to generated files somebody else did into the template file)
• Patches and pull/merge requests are hard to read, as the same changes appear multiple times (once in the template, and then once for every output file)
• If the list of generated files changes, either precheckin.sh has to take care of removing the old file, or the developer has to figure out that the file isn't generated, and has to manually git rm the outdated generated file (e.g. an outdated device variant is removed from being generated, then the associated output file also needs to be manually removed)
• Sometimes variants are generated from a base .spec file, making it harder to figure out which .spec file is the "template" one (e.g. precheckin.sh generates bar.spec from foo.spec via sed -e "s/FooFoo/BarBar/g" <foo.spec >bar.spec -- one has to read and understand precheckin.sh to figure out that bar.spec is read from foo.spec, and that foo.spec is used as "template" as well as "output")

I hereby propose a feature enhancement for tar_git, whereas:

• If the .spec file is not generated, it is stored in Git like now (rpm/<packagename>.spec), nothing changes
• If the .spec file(s) is/are (to be) generated:
  • The generated .spec files SHOULD NOT be stored in Git
  • The template file MUST NOT end in .spec (suggested: .spec.in, but not required, as it could theoretically be fully generated by rpm/precheckin.sh without any template file)
  • There MUST be a script rpm/precheckin.sh that is run by tar_git using a Bourne shell with the working directory being rpm/ (think: cd rpm && rm -f *.spec && sh precheckin.sh) after the Git checkout and that generates one or more .spec files
  • The rpm/precheckin.sh script MUST NOT assume that any .spec file exists, meaning that one cannot generate .spec file variants out of a base .spec file - the base .spec file must always be a template (e.g. .spec.in) -- this is to allow rm -f rpm/*.spec to remove leftover files, and to avoid situations like with bar.spec generated from foo.spec as described above
  • The rpm/precheckin.sh script SHOULD NOT have the executable bit (+x) set and the shebang line SHOULD BE #!/bin/sh (but is ignored, as it's run with sh precheckin.sh as above)
  • The rpm/precheckin.sh script MUST NOT use any bash-isms, only a normal Bourne shell should be assumed
  • Transitional feature: If the generated .spec file is stored in Git (as for all projects using generated .spec files up to now), it WILL BE overwritten by rpm/precheckin.sh
  • If rpm/precheckin.sh exists, it is always safe to run cd rpm && rm -f *.spec && sh precheckin.sh, this way, the script doesn't have to take care of removing outdated files (e.g. when a variant for an outdated device is removed, thereby causing less .spec files to be generated)
  • It is RECOMMENDED that projects that use rpm/precheckin.sh have rpm/*.spec (like this, with the glob) in their .gitignore files, to avoid accidentally adding/checking in generated .spec files during development

This specification allows local build tools such as mb2 to be eventually extended to generate and update .spec files on demand, and also provides a consistent way for developers to generate/update the .spec files manually (cd rpm && sh precheckin.sh).

In short:

• If rpm/precheckin.sh exists, any tooling or developer should assume that it/he/she needs to first rm rpm/*.spec and then run sh precheckin.sh (inside the rpm/ directory as working directory) before the list of .spec files is up to date and before any package building can take place. Any change in the source directory - even outside of rpm/ - should cause a re-run of rpm/precheckin.sh, as the precheckin.sh script might parse source code files to obtain values used in the .spec file -- tar_git will run this script after checkout

Or in code (assume fail is a function that prints the error message and then exits with non-zero exit status):

# Right after checkout (tar_git) OR just before build (mb2 / manual build)
if [ -f rpm/precheckin.sh ]; then
    cd rpm
    rm -f *.spec
    sh precheckin.sh || fail "Could not generate .spec files with precheckin.sh"
    cd ..
fi

Advantages that this gives us:

• We don't store redundant/generated files in Git
• Generated files will always be up to date
• We avoid users editing generated files and forgetting to update the templates
• There is a single, documented and simple way of generating .spec files
• Less frustration, more automation, consistency and fun(!)

Possible transitional disadvantages (= yes, we can't have nice things, there's a transitional cost):

• Some existing precheckin.sh scripts might assume that they are run from the project root
• Some existing precheckin.sh might require parameters, these need to be fixed
• We need to educate developers how to use the new feature, and fix existing packaging