Hi Fabio,
On Mon, Mar 19, 2018 at 8:18 AM, Fabio Niephaus lists@fniephaus.com wrote:
Hi all,
On Mon, Mar 19, 2018 at 3:49 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tobias,
On Mar 19, 2018, at 1:38 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi,
On 19.03.2018, at 01:56, Eliot Miranda eliot.miranda@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