Task to build core snaps in launchpad #49

Open
wants to merge 10 commits into
from

Conversation

Projects
None yet
5 participants
Contributor

sergiocazzolato commented Oct 3, 2017

This job triggers the builds in launchpad for the different
architectures every night, and tracks the relation between the build and
the commit in git to be used to run tests.

Still missing to implement a change in master to add the dependencies needed for this branch.
python packages: launchpadlib and urlparse2

sergiocazzolato added some commits Sep 25, 2017

Add configure files as part of the sync
Currently the files named "configure" are not sent to the syc-vendor
repo because configure name is on the .ignore file and prevents that
those files are added as part of the commits.
There are several files which were not copied so far:

./tests/lib/snaps/config-versions-v2/meta/hooks/configure
./tests/lib/snaps/config-versions/meta/hooks/configure
./tests/lib/snaps/snapctl-hooks/meta/hooks/configure
./tests/lib/snaps/basic-hooks/meta/hooks/configure
./tests/lib/snaps/snapctl-hooks-v2/meta/hooks/configure
./tests/lib/snaps/failing-config-hooks/meta/hooks/configure
./tests/lib/snaps/test-snapd-with-configure/meta/hooks/configure
./tests/lib/snaps/snapctl-from-snap/meta/hooks/configure
./tests/lib/snaps/snap-hooks/meta/hooks/configure
Task to build core snap in launchpad
This job triggers the builds in launchpad for the different
architectures every night, and tracks the relation between the build and
the commit in git to be used to run tests.

@sergiocazzolato sergiocazzolato requested review from mvo5, stolowski, zyga and niemeyer Oct 3, 2017

@sergiocazzolato sergiocazzolato changed the title from Task to build core snap in launchpad to Task to build core snaps in launchpad Oct 3, 2017

Thanks for working on this! This looks very good, some questions/suggestions inline.

lp-build-core.py
+
+# we need to store credentials once for cronned builds
+cachedir = os.path.join(workdir, 'cache')
+creds = os.path.join(workdir, 'credentials')
@mvo5

mvo5 Oct 4, 2017

Contributor

How will those credentials be injected here? And from what user (we have a function account for this, right?)

@sergiocazzolato

sergiocazzolato Oct 4, 2017

Contributor

I planned to add them manually once the branch is merged. I have to use an account with the permissions to trigger builds, and I though to use mine due these credentials can be used just on that machine. Does it make sense? any other idea?

@niemeyer

niemeyer Oct 23, 2017

How would that work? Will we have a machine sitting somewhere that can release core snaps arbitrarily?

@sergiocazzolato

sergiocazzolato Oct 23, 2017

Contributor

@niemeyer this will run in the same machine where we run the spread-cron branches. The access to this machine is restricted of course.

@niemeyer

niemeyer Oct 23, 2017

It's a CI machine getting a non-trivial amount of tip source code and running it on external systems. Unless there are more clear details about how "restricted of course" it is, I'd be super uncomfortable in trusting the security of the core snap to it.

@ogra1

ogra1 Oct 23, 2017

@niemeyer note that lp-build-core.py has originally been one of my shellscripts for the daily cronned build setup that i then ported to python (to make use of launchpad-lib), as such it indeed still looks like shell ;) when i gave it to sergio it was more meant as a suggestion... this should surely get re-worked a lot when integrating it somewhere in public code ...

this script simply triggers a pre-defined snap build in LP, so the "machine sitting somewhere" doing the releases is launchpad itself ... but ... unlike the set-up i use for the daily cronned builds the credentials are in your case not on a private machine (in my case it is people.canonical.com, in a dir not accessible by any outside person) so i dont really see how the credentials setup will work without leaking them to the outside world ...

@niemeyer

niemeyer Oct 24, 2017

For the record, shell scripts do have functions as well, and scoping. Non-trivial scripts ought to make good use of those.

lp-build-core.py
+ mybuilds.append(buildid)
+ print('Arch: {} is building under: {}'.format(buildarch, request))
+
+# check the status each minute til all builds have finished
@mvo5

mvo5 Oct 4, 2017

Contributor

typo: til -> until (I assume)

lp-build-core.py
+ for build in mybuilds:
+ try:
+ response = ubuntucore.getBuildSummariesForSnapBuildIds(snap_build_ids=[build])
+ except:
@mvo5

mvo5 Oct 4, 2017

Contributor

We should log the exception here, something like (untested):

except e:
  print('could not get response for {} (was there an LP timeout ?): {}'.format(build, e))
lp-build-core.py
+ failure, buildlog))
+ built_arches.remove(arch)
+
+# save a file with a line containing all the architectures that were built successfully
@mvo5

mvo5 Oct 4, 2017

Contributor

Maybe a small comment why this file is needed?

@@ -1,3 +1,2 @@
-pattern_extractor="curl -s https://api.travis-ci.org/repos/snapcore/snapd/builds?event_type=push | jq -j 'map(select(.result == 0) | select(.branch == \"master\")) | .[0].number'"
@mvo5

mvo5 Oct 4, 2017

Contributor

Hm, I'm slightly confused why there is an options file here that is overriden. Shouldn't the build-core-lp branch that we use (and target) be empty?

@sergiocazzolato

sergiocazzolato Oct 4, 2017

Contributor

I created the branch build-core-lp on snapcore/spread-cron to have one branch to compare in the pull request, but that branch is set as manual in the options file which means the branch is not executed by spread-cron. The final options file is the one you have here in the PR.

@sergiocazzolato

sergiocazzolato Oct 4, 2017

Contributor

I should have been created a PR for this manual branch I guess

run-checks
+export RESULTS_FILE=built_architectures.txt
+
+# build core for all the architectures
+output=0
@mvo5

mvo5 Oct 4, 2017

Contributor

Maybe result or res or exitcode instead of output? output sounds like some textual output to me.

run-checks
+#!/bin/sh
+
+mkdir -p bin
+( cd bin && wget https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz -O spread.tar.gz && tar xzvf spread.tar.gz )
@ogra1

ogra1 Oct 5, 2017

how about:
wget https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz -O - | zcat - | tar x

that saves disk space by directly streaming the tarball to disk (and you dont need to clean up temporary files ;) )

@sergiocazzolato

sergiocazzolato Oct 5, 2017

Contributor

@ogra1, good idea, thanks

It would be nice to have some minimum structure in that code. Note how there are zero functions, and every variable is a global. This is hard to read, maintain, review, reason about, etc.

Contributor

sergiocazzolato commented Oct 23, 2017

@niemeyer sure, you mean in the python script? I'll work on that. Thanks for reviewing this.

A few quick comments. I'll have more once I know if this is python 2.7 or python 3.x

@@ -0,0 +1,146 @@
+#!/usr/bin/python
+
@zyga

zyga Oct 24, 2017

If this is python 2.x can you please add

from __future__ import absolute_import, print_function

If this is python3 then please adjust the first line to read #!/usr/bin/python3

@ogra1

ogra1 Oct 24, 2017

originally this is python2 because it runs on people.canonical.com which is a 12.04 machine ...
also, since it has not been mentioned, the original script (and the README with basic instructions) is at:
https://github.com/snapcore/core/tree/master/cron-scripts

+ while len(self.builds):
+ elapsed_build_time = int((datetime.now() - self.start_build_time).total_seconds())
+ if timeout < elapsed_build_time:
+ print('Timeout reached')
@zyga

zyga Oct 24, 2017

Not that it strictly matters here but this could be some kind of new TimeoutError or even a plain old SystemExit

+
+ if status == 'FULLYBUILT':
+ self.builds.remove(build)
+ continue
@zyga

zyga Oct 24, 2017

The continue statements in each of the branches here are no-ops since this is the last statement in the loop body.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment