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?
_,,,^..^,,,_ best, Eliot
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?
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?
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
Hi Tobias,
On 19 March 2018 at 09:38, 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?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?
While we're on this topic, would you mind explaining the logic for transferring builds to bintray?
There hasn't been an update to https://bintray.com/opensmalltalk/vm/cog/ since March 8th, and I'm fairly sure there have been successful builds on travis.
Thanks, Alistair
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?
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 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/1f0a7da9d4e8dcf4cdf...
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
On 19-03-2018, at 8:18 AM, Fabio Niephaus lists@fniephaus.com wrote:
When a build is broken, the author of the corresponding commit receives an email with a link to the affected jobs.
Is there any way that can be extended to send mail to vm-dev (for example) so that a wider audience at least knows something has gone wrong? It would be smart to be able to handle a case where The Evil Culprit has gone home, or on vacation, or been kidnapped by the gray-alien lizard people and simply isn't in a position to see the message.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Inoculatte (v): To take coffee intravenously when you are running late
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
On 19 March 2018 at 22:48, 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?
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
Hi Ben, Hi All,
On Tue, Mar 20, 2018 at 3:45 AM, Ben Coman btc@openinworld.com wrote:
On 19 March 2018 at 22:48, 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?
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.
I like this idea. So we would have the src tree as described above. So if we change this what is impacted? here's a partial list. Can people please add to the list?
all makefiles under build, (and those generated by platforms/unix/config scripts) some of the platforms/unix/conf generation stuff, in particular platforms/unix/config/configure.ac README.md VMMaker generation specifications in VMMaker.oscog
Others? (checkout scripts for CI that check-out a subset of sources, etc?)
cheers -ben
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Alistair Grant -
Ben Coman -
Eliot Miranda -
Fabio Niephaus -
tim Rowledge -
Tobias Pape