why are the builds cancelled

 

Hi all,

On Mon, Mar 19, 2018 at 3:49 PM Eliot Miranda <[hidden email]> wrote:

Hi Tobias,

> On Mar 19, 2018, at 1:38 AM, Tobias Pape <[hidden email]> wrote:
>
>
> Hi,
>
>> On 19.03.2018, at 01:56, Eliot Miranda <[hidden email]> 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
>

Hi Tobias,

> On Mar 19, 2018, at 1:38 AM, Tobias Pape <[hidden email]> wrote:
>
>
> Hi,
>
>> On 19.03.2018, at 01:56, Eliot Miranda <[hidden email]> 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?
>
>
> 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.

 

On 19 March 2018 at 22:48, Eliot Miranda <[hidden email]> wrote:

Hi Tobias,

> On Mar 19, 2018, at 1:38 AM, Tobias Pape <[hidden email]> wrote:
>
>
> Hi,
>
>> On 19.03.2018, at 01:56, Eliot Miranda <[hidden email]> 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?
>
>
> 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.

From the sideline peanut gallery... the "build*" folders are not so bad since there are not so many of them, and they advertise what platforms are supported,

but the plethora of "*src*" directories is distracting, particularly with the explosion from sista/lowcode/32bit/64bit variants.  If they were all organised under a folder, would you consider also naming that parent folder "gensrc" or "src.gen" or similar to make it explicit for newcomers that these are generated sources.  A README in that folder might describe how the sources are generated.

cheers -ben