Message ID | 20200307030734.237401-1-sjg@chromium.org |
---|---|
Headers | show |
Series | gitlab: Simplify the test script | expand |
On Fri, Mar 06, 2020 at 08:07:14PM -0700, Simon Glass wrote: > At present there are several things in the gitlab script which work around > limitations in buildman. With a few small feature additions these can be > removed. > > This series adds some new features to buildman and simplifies the script: > - Option to run a single build in a specified output directory > - Allow ignoring warnings > - Removes a restriction on the build output directory > > It also > - moves test.py over to use buildman for the --build option > - makes one change to azure since the same approach should be possible there > - fixes a few minor problems noticed in main and sandbox docs One general comment is that while it's clear from this series that you're focusing on test.py invocation most of the time, a lot of the commit messages aren't clear that you're changing the buildman_and_testpy_template stanza. Also, while you're keeping Azure in sync (as it's largely based on the GitLab logic), Travis is being left out. But the GitLab logic is based on the Travis logic and as much as I dislike Travis for being slow and having network induced failures, it's still a valid and supported CI flow that we can't drop, so please keep it in sync with these improvements, thanks!
Hi Tom, On Mon, 9 Mar 2020 at 11:55, Tom Rini <trini at konsulko.com> wrote: > > On Fri, Mar 06, 2020 at 08:07:14PM -0700, Simon Glass wrote: > > > At present there are several things in the gitlab script which work around > > limitations in buildman. With a few small feature additions these can be > > removed. > > > > This series adds some new features to buildman and simplifies the script: > > - Option to run a single build in a specified output directory > > - Allow ignoring warnings > > - Removes a restriction on the build output directory > > > > It also > > - moves test.py over to use buildman for the --build option > > - makes one change to azure since the same approach should be possible there > > - fixes a few minor problems noticed in main and sandbox docs > > One general comment is that while it's clear from this series that > you're focusing on test.py invocation most of the time, a lot of the > commit messages aren't clear that you're changing the > buildman_and_testpy_template stanza. I'm not sure what you are looking for there. Do you want the commit message to mention which part of the gitlab file is being changed? > > Also, while you're keeping Azure in sync (as it's largely based on the > GitLab logic), Travis is being left out. But the GitLab logic is based > on the Travis logic and as much as I dislike Travis for being slow and > having network induced failures, it's still a valid and supported CI > flow that we can't drop, so please keep it in sync with these > improvements, thanks! OK. Regards, Simon
On Sat, Mar 14, 2020 at 09:10:09PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 9 Mar 2020 at 11:55, Tom Rini <trini at konsulko.com> wrote: > > > > On Fri, Mar 06, 2020 at 08:07:14PM -0700, Simon Glass wrote: > > > > > At present there are several things in the gitlab script which work around > > > limitations in buildman. With a few small feature additions these can be > > > removed. > > > > > > This series adds some new features to buildman and simplifies the script: > > > - Option to run a single build in a specified output directory > > > - Allow ignoring warnings > > > - Removes a restriction on the build output directory > > > > > > It also > > > - moves test.py over to use buildman for the --build option > > > - makes one change to azure since the same approach should be possible there > > > - fixes a few minor problems noticed in main and sandbox docs > > > > One general comment is that while it's clear from this series that > > you're focusing on test.py invocation most of the time, a lot of the > > commit messages aren't clear that you're changing the > > buildman_and_testpy_template stanza. > > I'm not sure what you are looking for there. Do you want the commit > message to mention which part of the gitlab file is being changed? I mean a lot of places say something like "Change gitlab ..." but aren't changing any of the world builds, only test.py stuff, so I would prefer "Change gitlab when using test.py ..." Thanks!
Hi Tom, On Sun, 15 Mar 2020 at 07:02, Tom Rini <trini at konsulko.com> wrote: > > On Sat, Mar 14, 2020 at 09:10:09PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 9 Mar 2020 at 11:55, Tom Rini <trini at konsulko.com> wrote: > > > > > > On Fri, Mar 06, 2020 at 08:07:14PM -0700, Simon Glass wrote: > > > > > > > At present there are several things in the gitlab script which work around > > > > limitations in buildman. With a few small feature additions these can be > > > > removed. > > > > > > > > This series adds some new features to buildman and simplifies the script: > > > > - Option to run a single build in a specified output directory > > > > - Allow ignoring warnings > > > > - Removes a restriction on the build output directory > > > > > > > > It also > > > > - moves test.py over to use buildman for the --build option > > > > - makes one change to azure since the same approach should be possible there > > > > - fixes a few minor problems noticed in main and sandbox docs > > > > > > One general comment is that while it's clear from this series that > > > you're focusing on test.py invocation most of the time, a lot of the > > > commit messages aren't clear that you're changing the > > > buildman_and_testpy_template stanza. > > > > I'm not sure what you are looking for there. Do you want the commit > > message to mention which part of the gitlab file is being changed? > > I mean a lot of places say something like "Change gitlab ..." but aren't > changing any of the world builds, only test.py stuff, so I would prefer > "Change gitlab when using test.py ..." OK I will try. I've got the changes to all three environments in a single commit at present, so we don't end up with double the commis. Or would you prefer it split out? One more thing...I notice that gitlab and azure use 'set -ex' to avoid needing to check errors in the script. Is is possible for travis to do that do, or is there some restriction? > Thanks! > > -- > Tom Regards, Simon
On Sun, Mar 15, 2020 at 09:07:48AM -0600, Simon Glass wrote: > Hi Tom, > > On Sun, 15 Mar 2020 at 07:02, Tom Rini <trini at konsulko.com> wrote: > > > > On Sat, Mar 14, 2020 at 09:10:09PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 9 Mar 2020 at 11:55, Tom Rini <trini at konsulko.com> wrote: > > > > > > > > On Fri, Mar 06, 2020 at 08:07:14PM -0700, Simon Glass wrote: > > > > > > > > > At present there are several things in the gitlab script which work around > > > > > limitations in buildman. With a few small feature additions these can be > > > > > removed. > > > > > > > > > > This series adds some new features to buildman and simplifies the script: > > > > > - Option to run a single build in a specified output directory > > > > > - Allow ignoring warnings > > > > > - Removes a restriction on the build output directory > > > > > > > > > > It also > > > > > - moves test.py over to use buildman for the --build option > > > > > - makes one change to azure since the same approach should be possible there > > > > > - fixes a few minor problems noticed in main and sandbox docs > > > > > > > > One general comment is that while it's clear from this series that > > > > you're focusing on test.py invocation most of the time, a lot of the > > > > commit messages aren't clear that you're changing the > > > > buildman_and_testpy_template stanza. > > > > > > I'm not sure what you are looking for there. Do you want the commit > > > message to mention which part of the gitlab file is being changed? > > > > I mean a lot of places say something like "Change gitlab ..." but aren't > > changing any of the world builds, only test.py stuff, so I would prefer > > "Change gitlab when using test.py ..." > > OK I will try. I've got the changes to all three environments in a > single commit at present, so we don't end up with double the commis. > Or would you prefer it split out? Doing all CIs in step makes sense. So something like...: Azure/GitLab/Travis: Change test.py and buildman ... > One more thing...I notice that gitlab and azure use 'set -ex' to avoid > needing to check errors in the script. Is is possible for travis to do > that do, or is there some restriction? Not sure. When in doubt I always hack the heck out of .travis.yml to just be a testcase of what I want to figure out, push and see. Thanks!