Request for stable, automated build process

[Joachim Steiger]

> I haven't been on a project where we pulled a significant amount of code
> from repositories not under our control, and I agree that changes things
> slightly.  It seems to me that it's more reason, not less, for CI, though.
> (Really, I think you're already on the same track...)

atleast for QA reasons. yeah.

> Assuming that the outside repository doesn't already have a way to
> find the latest good build, just use a dated pull from the repositories
> outside your control, and record the "label" in a file.  Use the latest
> good build date for the external code as your "label" to use when
> building the code that *is* under your control.

well.. much easier than that:
we just need to know the head revision of the OE repo which we use to
build since all the revisions for regular packages should be fixed to
known good ones.
dates are a really bad idea as tag, since they break due to timezones.
only real revisions should be used for pinning.
you can also disable this pinning in OE with something called autorev,
which would for example get the svn fetcher to use head instead of a
pinned version.

afaik we only use that 'feature' for our own stuff, and not upstream
packages.

> You would probably want a separate CI process for each externally
> controlled repository, plus one for all the OM controlled code.
> 
> Also, certainly for external code you would need to build on a
> schedule, rather than restarting the build when new checkins
> happen.  Really, you should probably do the same for your
> internal code, too, though.  (With the caveat that you only
> build your internal code at the scheduled time if changes have
> been checked in).

this isn't really a concern due to the pinning i described above.
means without anybody changing the revision to be used of some upstream
code in OE it will stay the same forever. this enables incremental
builds being quite fast while oe still should know when to rebuild if
somebody updates the recipe with a new(higher) PR or a new version.

but i think our OE crowd can explain these details much better than i can.


-- 

Joachim Steiger
developer relations/support