[Vm-dev] why are the builds cancelled

[Eliot Miranda]

Hi Fabio,

On Mon, Mar 19, 2018 at 8:18 AM, Fabio Niephaus <lists at fniephaus.com> wrote:

>
> 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
>

thanks!  That was my bad.  I've committed the fixes.  Things should be back
to normal now.


>
>
>
>> >
>> >
>> > 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
>> >
>>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180319/a9cd2efc/attachment.html>