[Vm-dev] why are the builds cancelled
Fabio Niephaus
lists at fniephaus.com
Mon Mar 19 15:18:25 UTC 2018
Hi all,
On Mon, Mar 19, 2018 at 3:49 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:
>
> Hi Tobias,
>
> > On Mar 19, 2018, at 1:38 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >
> >
> > Hi,
> >
> >> On 19.03.2018, at 01:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> Travis isn't building new commits and I don't know why. Can someone
> update the README.md for opensmalltalk/vm with a pointer to an overview of
> the Travis CI infrastructure so that someone could work out why things
> aren't working?
>
I'll add this to my todo and hope I can add some info soon.
When a build is broken, the author of the corresponding commit receives an
email with a link to the affected jobs.
Currently, builds are broken because of:
`../../editnewspeakinstall.sh: line 5: cd:
../../../products/nscogspur64linuxht: No such file or directory` (see [1])
An overview of all recent builds is at [2] which suggests that CI broke on
[3].
Fabio
[1]
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/354870587#L2133
[2] https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds
[3]
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
> >
> >
> > Things are working ;)
> > What happens is: we're using build stages to minimize load on travis and
> to get faster feedback.
> >
> > Let's take this as an example:
> > https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/354870586
> >
> > We currently have four stages:
> > - Linux builds
> > - Mac builds
> > - Stack builds
> > - Linux32armv6 builds
> >
> > Each stage will only start iff the previous stage completed
> successfully, essentially saying "if those builds did not run, don't even
> bother looking at me"
> >
> > So, since the Linux builds did not complete all (in fact, only one did),
> all subsequent stages are ignored.
> >
> > This actually ensures that we get swifter response, as later builds are
> more likely to run.
> >
> > Does that help?
>
> Yes, but... :-). Forgive the "but". The issue is I had to ask and
> couldn't work it out myself. What would really help would be a paragraph
> in README.md that gives an overview of the build slave and of bintray.
> Something like
>
> "The various VMs are built and tested using Travis CI at ... Successful
> builds are uploaded to bintray for download at... The tests determining a
> "successful build" are...
>
> I wrote the initial draft of README.md and now I find it too chatty and
> not well laid out. Much of my content could be relegated to a "VM Source
> Generation" subsection and the intro could be firmed up and aimed at the
> general reader. What I'm saying is that if someone does edit README.md to
> include pointers to the CI build pipeline, they shouldn't be afraid of
> improving the overall structure of README.md.
>
> On a related note, README.md is buried in a long list of top level
> directories. Personally, keeping the directory hierarchy relatively flat
> helps me when fixing things. Often one is in a build directory and it's
> nice to avoid an additional ../. And of course changing the layout means
> fixing not just makefiles, but the autoconf stuff in platforms/unix/conf
> and Travis stuff and the VMMaker source and... and making this change just
> to make README.md more prominent seems like putting the cart before the
> horse, the tail wagging the dog, etc. so one simple layout change would be
> to move all the build.*, *src, platforms, processors, .third-party stuff
> down into a directory (software?). Or do people feel strongly that it
> should be reorganised, e.g. as
>
> src/
> plugins/
> spur/
> spur64/
> v3/
> build/
> linux32ARMv6
> ...
>
> I'm for as little busy work as possible. But recognize that README.md is
> an important portal on the project, so it needs to be prominent and well
> laid out, a principle reader being the first-time reader trying to work out
> how to get at builds or to start building their own.
>
> >
> > Best regards
> > -Tobias
> >
> >
> >
> >>
> >> _,,,^..^,,,_
> >> best, Eliot
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180319/f49d11cb/attachment-0001.html>
More information about the Vm-dev
mailing list