Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
1) Release builds stay forever 2) Official daily builds kept for 3 months 3) Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
It's not clear what the new expiration script will do. Can you summarize what will change?
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
Also discussed during Leads meeting:
1. make a "release build" tab; keep release builds forever confirmed 2. make a "regression build" tab where all the variation builds we don't officially release go; those will get a 1 month retention 3. later: rename the Official build tab to something better.
With that a bunch of currently official builds will get a reduced retention which would give us more room to breeze.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
Hello,
On Wed, 26 Sep 2012 14:00:59 +0200 Alexander Sack asac@linaro.org wrote:
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
It's not clear what the new expiration script will do. Can you summarize what will change?
Nothing will change, but new functionality will be added: there will be a cronjob (in Python) which will read job configs and apply expiration settings in them unconditionally, unlike Jenkins, which applies them only in case a build is made.
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
Also discussed during Leads meeting:
- make a "release build" tab; keep release builds forever confirmed
- make a "regression build" tab where all the variation builds we
don't officially release go; those will get a 1 month retention 3. later: rename the Official build tab to something better.
As far as I can tell, all new tabs would go into new CI Dashboard which is being developed by Infrastructure now. Danilo may have better insight though.
With that a bunch of currently official builds will get a reduced retention which would give us more room to breeze.
With my maintenance-engineer-for-this-cycle hat on, I don't think any other changes besides those proposed above are needed at this time - we already have good retention policy, we just need to make sure it's actually enforced. We can queue more changes for future planning and implementation of course.
On Wed, Sep 26, 2012 at 11:54 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
On Wed, 26 Sep 2012 14:00:59 +0200 Alexander Sack asac@linaro.org wrote:
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
It's not clear what the new expiration script will do. Can you summarize what will change?
Nothing will change, but new functionality will be added: there will be a cronjob (in Python) which will read job configs and apply expiration settings in them unconditionally, unlike Jenkins, which applies them only in case a build is made.
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
Also discussed during Leads meeting:
- make a "release build" tab; keep release builds forever confirmed
- make a "regression build" tab where all the variation builds we
don't officially release go; those will get a 1 month retention 3. later: rename the Official build tab to something better.
As far as I can tell, all new tabs would go into new CI Dashboard which is being developed by Infrastructure now. Danilo may have better insight though.
CI dashboard is far ahead from . I don't see this land in production before early next year.
While I agree we shouldn't put massive efforts into android-build before that, I feel hesitant to stop all refinements because of that.
With that a bunch of currently official builds will get a reduced retention which would give us more room to breeze.
With my maintenance-engineer-for-this-cycle hat on, I don't think any other changes besides those proposed above are needed at this time - we already have good retention policy, we just need to make sure it's actually enforced. We can queue more changes for future planning and implementation of course.
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
What harm do those empty jobs do? Could we move them to a "archived build configurations" tab? or "Build Graveyard"?
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
Hello,
On Wed, 26 Sep 2012 14:02:12 +0200 Alexander Sack asac@linaro.org wrote:
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
What harm do those empty jobs do? Could we move them to a "archived build configurations" tab? or "Build Graveyard"?
They complicate Jenkins maintenance - it's hard to see live jobs among the cruft. So, do old empty jobs do any good to be preserved instead?
Hello,
Status update on this: Before proceeding with writing the standalone Python script described, I did another googling pass to find native Jenkins solution for a problem, even though previous my attempts didn't give much (but that might have been a year or so ago). Fortunately, this time I found some hints regarding this problem, it was suggested to use builtin Groovy interpreter which has good (complete?) native Jenkins API access.
So, such script is now cron'ized to run daily. On first day, it recovered 170Gb of free space (1/3 of entire disk space). It however implements a bit weaker expiration as our policy requires, but taking into account that questions/concerns were raised regarding proposal to remove old empty jobs, let's consider that a feature. (And I'm not proceeding with further work on this, as the main aim of maintaining enough free disk space was achieved).
More details may be available at https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546
Please let me know if there're further questions/suggestions regarding this.
Thanks, Paul
On Thu, 27 Sep 2012 00:57:04 +0300 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
Hello,
On Wed, 26 Sep 2012 14:02:12 +0200 Alexander Sack asac@linaro.org wrote:
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
What harm do those empty jobs do? Could we move them to a "archived build configurations" tab? or "Build Graveyard"?
They complicate Jenkins maintenance - it's hard to see live jobs among the cruft. So, do old empty jobs do any good to be preserved instead?
On 3 October 2012 05:02, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
Status update on this: Before proceeding with writing the standalone Python script described, I did another googling pass to find native Jenkins solution for a problem, even though previous my attempts didn't give much (but that might have been a year or so ago). Fortunately, this time I found some hints regarding this problem, it was suggested to use builtin Groovy interpreter which has good (complete?) native Jenkins API access.
So, such script is now cron'ized to run daily. On first day, it recovered 170Gb of free space (1/3 of entire disk space). It however implements a bit weaker expiration as our policy requires, but taking into account that questions/concerns were raised regarding proposal to remove old empty jobs, let's consider that a feature. (And I'm not proceeding with further work on this, as the main aim of maintaining enough free disk space was achieved).
More details may be available at https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546
Please let me know if there're further questions/suggestions regarding this.
Awesome Paul. Thanks!
Thanks, Paul
On Thu, 27 Sep 2012 00:57:04 +0300 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
Hello,
On Wed, 26 Sep 2012 14:02:12 +0200 Alexander Sack asac@linaro.org wrote:
On Wed, Sep 26, 2012 at 1:49 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example, https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
What harm do those empty jobs do? Could we move them to a "archived build configurations" tab? or "Build Graveyard"?
They complicate Jenkins maintenance - it's hard to see live jobs among the cruft. So, do old empty jobs do any good to be preserved instead?
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On 26 September 2012 06:49, Paul Sokolovsky paul.sokolovsky@linaro.orgwrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example,
https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
What if we simplify this. We introduce a build variable that's a date or a value. Builds without such a variable disappear in a week, builds with it expire on the date show, builds marked FOREVER stick around.
Also, what about the underling disk space issues. Android build sizes will keep going up and the number of Android builds will keep going up. Can we just get a bigger disk?
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
Hello,
On Wed, 26 Sep 2012 14:20:17 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 26 September 2012 06:49, Paul Sokolovsky paul.sokolovsky@linaro.orgwrote:
Hello,
We keep having cases of out of disk space, latest we had is https://bugs.launchpad.net/linaro-android-infrastructure/+bug/1055546 . The reason this happens so often is that Jenkins has a broken build expiration process - it is applied to jobs which are actually built. If a job is left unattended, its builds will stay forever. This is long-standing known issue, and I manually deleted stale builds in this case, while queuing need to write a script for that, which I'm going to start with now.
To remind, we have following build retention policy:
- Release builds stay forever
- Official daily builds kept for 3 months
- Personal builds kept for 1 month
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Zach, Fathi, Alexander, can you please do the same for old official builds. For example,
https://android-build.linaro.org/jenkins/view/Official%20builds/job/linaro-a... would be gone completely.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs, Zach - 8, etc. Do you still need them? Otherwise, I'd propose to add another clause to the policy and remove such empty jobs if not updated within last 3 months. Let me know what you think.
What if we simplify this. We introduce a build variable that's a date or a value. Builds without such a variable disappear in a week, builds with it expire on the date show, builds marked FOREVER stick around.
I'm not sure that would be simplification: 1) it will need to be implemented; 2) people will need to know about and it not forget to use it. As I mentioned in the reply to Alexander, I don't think that we need any other actions at this time - we (Infrastructure) just need to implement existing policies thoroughly. If you think that changes above are important, please discuss them with Danilo for scheduling.
Also, what about the underling disk space issues. Android build sizes will keep going up and the number of Android builds will keep going up. Can we just get a bigger disk?
So far, large share of disk space is occupied by cruft, and size of that goes up faster than size of builds to retain. So, no matter how much disk space we get, without proper management, it will be filled in very quickly (much quicker than expected). At least that's how it was so far, so let's try to address space management issues now.
On 26 September 2012 04:49, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Can we have a "keep this indefinitely" checkbox on builds? I think that's primarily useful to keep around the last build when support for a platform is dropped (Beagle, iMX53, iMX6, ...), but also to keep a specific build around for debugging (e.g. last build showing a bug that stopped appearing, but where we know it's not fixed -- e.g. hidden due to different timing)
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs,
I've killed most of them. Keeping imx6-test for now just in case we ever want to revive support for it.
ttyl bero
On 26 September 2012 17:19, Bernhard Rosenkränzer < bernhard.rosenkranzer@linaro.org> wrote:
On 26 September 2012 04:49, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Can we have a "keep this indefinitely" checkbox on builds? I think that's primarily useful to keep around the last build when support for a platform is dropped (Beagle, iMX53, iMX6, ...), but also to keep a specific build around for debugging (e.g. last build showing a bug that stopped appearing, but where we know it's not fixed -- e.g. hidden due to different timing)
This is a good idea Bero, Paul/Danilo do you think this is a reasonable improvement you could make in 12.10? You could also then set the retention policy for anything not kept to 1 week. Thoughts?
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs,
I've killed most of them. Keeping imx6-test for now just in case we ever want to revive support for it.
ttyl bero
Hello Bernhard,
On Wed, 26 Sep 2012 15:19:39 -0700 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
On 26 September 2012 04:49, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Can we have a "keep this indefinitely" checkbox on builds?
There's such feature in Jenkins. It is not exposed in Build Frontend though. For example, when logged in with job edit permission, go to https://android-build.linaro.org/jenkins/job/berolinux_nexus7-jb-gcc47-aosp-... , at the top right corner of page, there's "Keep this build forever" button. Then, there's "add description" link-button, which allows to add notes to a build.
I think that's primarily useful to keep around the last build when support for a platform is dropped (Beagle, iMX53, iMX6, ...), but also to keep a specific build around for debugging (e.g. last build showing a bug that stopped appearing, but where we know it's not fixed -- e.g. hidden due to different timing)
Definitely, that's useful. When I was full-time on Android build infra, I used those features myself to annotate type of breakage a build had, or mark last build before an Android version upgrade and first after, etc. (cannot give examples, because we had several rounds of build renames since, so I cannot quickly find an instance).
Well, I never had a feedback that someone finds my annotations useful, or even notices them. (And there's of course good reason for that - we wanted people to use frontend, so people used it, while annotations are in Jenkins).
Bernard, as you have enough access to Jenkins to use those features, I'd welcome you to try them, and let's see how useful and used they actually will be.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs,
I've killed most of them. Keeping imx6-test for now just in case we ever want to revive support for it.
Thanks!
ttyl bero
On 1 October 2012 15:11, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello Bernhard,
On Wed, 26 Sep 2012 15:19:39 -0700 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
On 26 September 2012 04:49, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
With new expiration script to be developed, many builds will be "suddenly" (but in full accordance with the policy above) gone. So, I would like to ask all Android developers to look thru their builds to check if you need anything old (and preserve it somewhere else then).
Can we have a "keep this indefinitely" checkbox on builds?
There's such feature in Jenkins. It is not exposed in Build Frontend though. For example, when logged in with job edit permission, go to https://android-build.linaro.org/jenkins/job/berolinux_nexus7-jb-gcc47-aosp-... , at the top right corner of page, there's "Keep this build forever" button. Then, there's "add description" link-button, which allows to add notes to a build.
the feature in Jenkins isn't a panacea. It doesn't propagate to snapshots.linaro.org, where we use pruning scripts (totally disconnected from the Jenkins feature). It will work on android-build itself, where we have logs, etc...
I think that's primarily useful to keep around the last build when support for a platform is dropped (Beagle, iMX53, iMX6, ...), but also to keep a specific build around for debugging (e.g. last build showing a bug that stopped appearing, but where we know it's not fixed -- e.g. hidden due to different timing)
Definitely, that's useful. When I was full-time on Android build infra, I used those features myself to annotate type of breakage a build had, or mark last build before an Android version upgrade and first after, etc. (cannot give examples, because we had several rounds of build renames since, so I cannot quickly find an instance).
Well, I never had a feedback that someone finds my annotations useful, or even notices them. (And there's of course good reason for that - we wanted people to use frontend, so people used it, while annotations are in Jenkins).
Bernard, as you have enough access to Jenkins to use those features, I'd welcome you to try them, and let's see how useful and used they actually will be.
In addition to the above, the issue we may have that there're lot of empty personal jobs piled up (with builds removed per the policy above). They clutter view largely, for example, Bero has 10 such jobs,
I've killed most of them. Keeping imx6-test for now just in case we ever want to revive support for it.
Thanks!
ttyl bero
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-android@lists.linaro.org
-
Alexander Sack -
Bernhard Rosenkränzer -
Fathi Boudra -
Paul Sokolovsky -
Zach Pfeffer