Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1402923003:
Landmines support to ease clobbering builds (Closed)
|
Created:
5 years, 2 months ago by kjellander_webrtc Modified:
5 years, 1 month ago CC:
webrtc-reviews_webrtc.org, yujie_mao (webrtc), Andrew MacDonald, tterriberry_mozilla.com, qiang.lu, niklas.enbom, peah-webrtc Base URL:
https://chromium.googlesource.com/external/webrtc.git@master Target Ref:
refs/pending/heads/master Project:
webrtc Visibility:
Public. |
DescriptionLandmines support to ease clobbering builds
Landmines is a feature used in Chromium that makes it possible to
clobber the build output directory when needed. Example scenarios
are when compiler/tool/infrastructure changes require a full rebuild.
This is mainly to ease clobbering on all bots, but will also ensure
developers don't have to waste time on figuring out what's wrong
(or rely on reading PSA e-mails announcing when such manual action
is required).
This CL depends on https://codereview.chromium.org/1407733002/
being landed and rolled into DEPS first.
BUG=webrtc:5077
R=kjellander@chromium.org, machenbach@chromium.org
Committed: https://chromium.googlesource.com/external/webrtc/+/27576e0b68cff41d0b28cdd38543e85805ac49bf
Patch Set 1 #
Total comments: 4
Patch Set 2 : Added comment #Patch Set 3 : Making sure the hook runs after Chromium download and symlinks setup #Patch Set 4 : Removed initial landmine #
Messages
Total messages: 22 (3 generated)
kjellander@webrtc.org changed reviewers: + machenbach@chromium.org
This is to ensure I have an easy way to clobber before landing https://codereview.chromium.org/1400283004/
On 2015/10/14 15:00:30, kjellander (webrtc) wrote: > This is to ensure I have an easy way to clobber before landing > https://codereview.chromium.org/1400283004/ The required Chromium change has now been rolled in with https://codereview.webrtc.org/1405513005/
On 2015/10/14 20:47:37, kjellander (webrtc) wrote: > On 2015/10/14 15:00:30, kjellander (webrtc) wrote: > > This is to ensure I have an easy way to clobber before landing > > https://codereview.chromium.org/1400283004/ > > The required Chromium change has now been rolled in with > https://codereview.webrtc.org/1405513005/ It seems best to wait a little so all bots have synced at least once past that roll (since pulling Chromium happens in a later hook than the one I'm adding, it will need to run first). I'll give it a day then retry.
lgtm with comments: https://codereview.chromium.org/1402923003/diff/1/DEPS File DEPS (right): https://codereview.chromium.org/1402923003/diff/1/DEPS#newcode62 DEPS:62: 'src', How is that different to the old default value SRC_DIR in chromium's landmines script? Why is only one trybot failing and not all? Did they sync do different chromium versions? https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.py File webrtc/build/get_landmines.py (right): https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.... webrtc/build/get_landmines.py:18: script_dir = os.path.dirname(os.path.realpath(__file__)) Lines 18-28 allow optimizations, i.e. you can use those tools to not clobber on all platforms etc. But if that's not of importance for webrtc (i.e. if you build fast enough) you could also delete those to not confuse people.
kjellander@chromium.org changed reviewers: + kjellander@chromium.org
lgtm https://codereview.chromium.org/1402923003/diff/1/DEPS File DEPS (right): https://codereview.chromium.org/1402923003/diff/1/DEPS#newcode62 DEPS:62: 'src', On 2015/10/15 07:38:20, Michael Achenbach wrote: > How is that different to the old default value SRC_DIR in chromium's landmines > script? I understand your confusion, but since we're using symlinks the actual script location is chromium/src/build/ so when it tries to lookup the root, it will become chromium/src and thus put the .landmines file in there, which itself is probably OK, but I wanted to keep things clean. > Why is only one trybot failing and not all? Did they sync do different chromium > versions? It's because we have pools of machines shared between the trybots to optimize the throughput. Not all machines had performed a build on all their checkouts yet (which is one of the large disadvantages with that approach). https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.py File webrtc/build/get_landmines.py (right): https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.... webrtc/build/get_landmines.py:18: script_dir = os.path.dirname(os.path.realpath(__file__)) On 2015/10/15 07:38:20, Michael Achenbach wrote: > Lines 18-28 allow optimizations, i.e. you can use those tools to not clobber on > all platforms etc. But if that's not of importance for webrtc (i.e. if you build > fast enough) you could also delete those to not confuse people. I left them in there for simplicity when adding future clobbering for specific configurations. I also added a link to the Chromium get_landmines.py so it's easy to find examples of usage.
On 2015/10/15 10:51:41, kjellander (chromium) wrote: > lgtm Whops, wrong button :) but it does look good to me, heh. > > https://codereview.chromium.org/1402923003/diff/1/DEPS > File DEPS (right): > > https://codereview.chromium.org/1402923003/diff/1/DEPS#newcode62 > DEPS:62: 'src', > On 2015/10/15 07:38:20, Michael Achenbach wrote: > > How is that different to the old default value SRC_DIR in chromium's landmines > > script? > > I understand your confusion, but since we're using symlinks the actual script > location is chromium/src/build/ so when it tries to lookup the root, it will > become chromium/src and thus put the .landmines file in there, which itself is > probably OK, but I wanted to keep things clean. > > > Why is only one trybot failing and not all? Did they sync do different > chromium > > versions? > > It's because we have pools of machines shared between the trybots to optimize > the throughput. Not all machines had performed a build on all their checkouts > yet (which is one of the large disadvantages with that approach). > > https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.py > File webrtc/build/get_landmines.py (right): > > https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.... > webrtc/build/get_landmines.py:18: script_dir = > os.path.dirname(os.path.realpath(__file__)) > On 2015/10/15 07:38:20, Michael Achenbach wrote: > > Lines 18-28 allow optimizations, i.e. you can use those tools to not clobber > on > > all platforms etc. But if that's not of importance for webrtc (i.e. if you > build > > fast enough) you could also delete those to not confuse people. > > I left them in there for simplicity when adding future clobbering for specific > configurations. > I also added a link to the Chromium get_landmines.py so it's easy to find > examples of usage.
On 2015/10/15 10:52:10, kjellander (chromium) wrote: > On 2015/10/15 10:51:41, kjellander (chromium) wrote: > > lgtm > Whops, wrong button :) but it does look good to me, heh. Actually not. I just realized the hook needs to run after syncing Chromium + setting up the links on clean checkouts, or it will just fail. > > > > > https://codereview.chromium.org/1402923003/diff/1/DEPS > > File DEPS (right): > > > > https://codereview.chromium.org/1402923003/diff/1/DEPS#newcode62 > > DEPS:62: 'src', > > On 2015/10/15 07:38:20, Michael Achenbach wrote: > > > How is that different to the old default value SRC_DIR in chromium's > landmines > > > script? > > > > I understand your confusion, but since we're using symlinks the actual script > > location is chromium/src/build/ so when it tries to lookup the root, it will > > become chromium/src and thus put the .landmines file in there, which itself is > > probably OK, but I wanted to keep things clean. > > > > > Why is only one trybot failing and not all? Did they sync do different > > chromium > > > versions? > > > > It's because we have pools of machines shared between the trybots to optimize > > the throughput. Not all machines had performed a build on all their checkouts > > yet (which is one of the large disadvantages with that approach). > > > > > https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.py > > File webrtc/build/get_landmines.py (right): > > > > > https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.... > > webrtc/build/get_landmines.py:18: script_dir = > > os.path.dirname(os.path.realpath(__file__)) > > On 2015/10/15 07:38:20, Michael Achenbach wrote: > > > Lines 18-28 allow optimizations, i.e. you can use those tools to not clobber > > on > > > all platforms etc. But if that's not of importance for webrtc (i.e. if you > > build > > > fast enough) you could also delete those to not confuse people. > > > > I left them in there for simplicity when adding future clobbering for specific > > configurations. > > I also added a link to the Chromium get_landmines.py so it's easy to find > > examples of usage.
On 2015/10/15 11:15:52, kjellander (webrtc) wrote: > On 2015/10/15 10:52:10, kjellander (chromium) wrote: > > On 2015/10/15 10:51:41, kjellander (chromium) wrote: > > > lgtm > > Whops, wrong button :) but it does look good to me, heh. > > Actually not. I just realized the hook needs to run after syncing Chromium + > setting up the links on clean checkouts, or it will just fail. Some more testing also showed that the first landmine doesn't have any effect if there's no previous .landmines file. So I'll land this without any landmines and do a separate CL for the one to move past the GN build. > > > > > > > > > https://codereview.chromium.org/1402923003/diff/1/DEPS > > > File DEPS (right): > > > > > > https://codereview.chromium.org/1402923003/diff/1/DEPS#newcode62 > > > DEPS:62: 'src', > > > On 2015/10/15 07:38:20, Michael Achenbach wrote: > > > > How is that different to the old default value SRC_DIR in chromium's > > landmines > > > > script? > > > > > > I understand your confusion, but since we're using symlinks the actual > script > > > location is chromium/src/build/ so when it tries to lookup the root, it will > > > become chromium/src and thus put the .landmines file in there, which itself > is > > > probably OK, but I wanted to keep things clean. > > > > > > > Why is only one trybot failing and not all? Did they sync do different > > > chromium > > > > versions? > > > > > > It's because we have pools of machines shared between the trybots to > optimize > > > the throughput. Not all machines had performed a build on all their > checkouts > > > yet (which is one of the large disadvantages with that approach). > > > > > > > > > https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.py > > > File webrtc/build/get_landmines.py (right): > > > > > > > > > https://codereview.chromium.org/1402923003/diff/1/webrtc/build/get_landmines.... > > > webrtc/build/get_landmines.py:18: script_dir = > > > os.path.dirname(os.path.realpath(__file__)) > > > On 2015/10/15 07:38:20, Michael Achenbach wrote: > > > > Lines 18-28 allow optimizations, i.e. you can use those tools to not > clobber > > > on > > > > all platforms etc. But if that's not of importance for webrtc (i.e. if you > > > build > > > > fast enough) you could also delete those to not confuse people. > > > > > > I left them in there for simplicity when adding future clobbering for > specific > > > configurations. > > > I also added a link to the Chromium get_landmines.py so it's easy to find > > > examples of usage.
> Some more testing also showed that the first landmine doesn't have any effect if > there's no previous .landmines file. So I'll land this without any landmines and > do a separate CL for the one to move past the GN build. Hmm, that's a bit odd. Can it work then at all? I'd have assumed a missing .landmines always triggers a clobber. Because you can't guarantee that every checkout folder will be used between this CL and the first landmine. There might be checkouts that miss the .landmines file and checkout a landmine. Will they trigger or not?
On 2015/10/15 11:30:04, Michael Achenbach wrote: > > Some more testing also showed that the first landmine doesn't have any effect > if > > there's no previous .landmines file. So I'll land this without any landmines > and > > do a separate CL for the one to move past the GN build. > > Hmm, that's a bit odd. Can it work then at all? I'd have assumed a missing > .landmines always triggers a clobber. Because you can't guarantee that every > checkout folder will be used between this CL and the first landmine. There might > be checkouts that miss the .landmines file and checkout a landmine. Will they > trigger or not? My local testing shows that if you're missing .landmines you won't get anything clobbered. I would guess it's by design since if you have a clean checkout, you won't have anything to clobber anyway. What cases can you think of when you would like to clobber and would be missing the .landmines?
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/27576e0b68cff41d0b28cdd38543e85805ac49bf Cr-Commit-Position: refs/heads/master@{#10287}
Message was sent while issue was closed.
Committed patchset #4 (id:60001) manually as 27576e0b68cff41d0b28cdd38543e85805ac49bf (presubmit successful).
Message was sent while issue was closed.
> My local testing shows that if you're missing .landmines you won't get anything > clobbered. > I would guess it's by design since if you have a clean checkout, you won't have > anything to clobber anyway. > What cases can you think of when you would like to clobber and would be missing > the .landmines? Exactly the case you have here now. Here's the timeline: 1. bot builds with checkout in state A 2. you commit the landmines support CL as B 3. you commit whatever needs a landmine as C 4. you commit a landmine as D 5. bot builds with checkout in state D It's important that the bot (in a particular slavedir) didn't build between 1 and 5. The build will have the incremental difference of A and D (i.e. the checkout isn't fresh), but won't execute the clobber. With a big enough slave pool there is always a chance that there are some bots in that state. You won't know which until you run into.
Message was sent while issue was closed.
On 2015/10/15 12:26:19, Michael Achenbach wrote: > > My local testing shows that if you're missing .landmines you won't get > anything > > clobbered. > > I would guess it's by design since if you have a clean checkout, you won't > have > > anything to clobber anyway. > > What cases can you think of when you would like to clobber and would be > missing > > the .landmines? > > Exactly the case you have here now. Here's the timeline: > > 1. bot builds with checkout in state A > 2. you commit the landmines support CL as B > 3. you commit whatever needs a landmine as C > 4. you commit a landmine as D > 5. bot builds with checkout in state D > > It's important that the bot (in a particular slavedir) didn't build between 1 > and 5. The build will have the incremental difference of A and D (i.e. the > checkout isn't fresh), but won't execute the clobber. With a big enough slave > pool there is always a chance that there are some bots in that state. You won't > know which until you run into. The probability get lower that this happens with increased time between 2 and 4. And each time a compile fails, compile.py nukes the out dir anyway, so it might clean up itself...
Message was sent while issue was closed.
On 2015/10/15 12:36:24, Michael Achenbach wrote: > On 2015/10/15 12:26:19, Michael Achenbach wrote: > > > My local testing shows that if you're missing .landmines you won't get > > anything > > > clobbered. > > > I would guess it's by design since if you have a clean checkout, you won't > > have > > > anything to clobber anyway. > > > What cases can you think of when you would like to clobber and would be > > missing > > > the .landmines? > > > > Exactly the case you have here now. Here's the timeline: > > > > 1. bot builds with checkout in state A > > 2. you commit the landmines support CL as B > > 3. you commit whatever needs a landmine as C > > 4. you commit a landmine as D > > 5. bot builds with checkout in state D > > > > It's important that the bot (in a particular slavedir) didn't build between 1 > > and 5. The build will have the incremental difference of A and D (i.e. the > > checkout isn't fresh), but won't execute the clobber. With a big enough slave > > pool there is always a chance that there are some bots in that state. You > > won't know which until you run into. You're right. This calls for me waiting at least a day (or even more) with submitting my GN change that's known to break. I should ensure all bots have run a build with this CL so all slaves that has the bad args.gn files in the out/ has gotten the chance to get a .landmines file. > > The probability get lower that this happens with increased time between 2 and 4. > And each time a compile fails, compile.py nukes the out dir anyway, so it might > clean up itself... True, at least now I have a better tool than before to avoid wiping all the slaves. Doing it at a few machines is fine with me, worst case.
Message was sent while issue was closed.
On 2015/10/15 12:51:26, kjellander (webrtc) wrote: > On 2015/10/15 12:36:24, Michael Achenbach wrote: > > On 2015/10/15 12:26:19, Michael Achenbach wrote: > > > > My local testing shows that if you're missing .landmines you won't get > > > anything > > > > clobbered. > > > > I would guess it's by design since if you have a clean checkout, you won't > > > have > > > > anything to clobber anyway. > > > > What cases can you think of when you would like to clobber and would be > > > missing > > > > the .landmines? > > > > > > Exactly the case you have here now. Here's the timeline: > > > > > > 1. bot builds with checkout in state A > > > 2. you commit the landmines support CL as B > > > 3. you commit whatever needs a landmine as C > > > 4. you commit a landmine as D > > > 5. bot builds with checkout in state D > > > > > > It's important that the bot (in a particular slavedir) didn't build between > 1 > > > and 5. The build will have the incremental difference of A and D (i.e. the > > > checkout isn't fresh), but won't execute the clobber. With a big enough > slave > > > pool there is always a chance that there are some bots in that state. You > > > won't know which until you run into. > > You're right. This calls for me waiting at least a day (or even more) with > submitting my GN change that's known to break. I should ensure all bots have run > a build with this CL so all slaves that has the bad args.gn files in the out/ > has gotten the chance to get a .landmines file. > > > > > The probability get lower that this happens with increased time between 2 and > 4. > > And each time a compile fails, compile.py nukes the out dir anyway, so it > might > > clean up itself... > > True, at least now I have a better tool than before to avoid wiping all the > slaves. > Doing it at a few machines is fine with me, worst case. Ah, and because I ran into that before, I tuned our landmines implementation a bit: https://code.google.com/p/chromium/codesearch#chromium/src/v8/build/landmines... Chromium's doesn't have this. Maybe it just should?
Message was sent while issue was closed.
On 2015/10/15 12:58:51, Michael Achenbach wrote: > On 2015/10/15 12:51:26, kjellander (webrtc) wrote: > > On 2015/10/15 12:36:24, Michael Achenbach wrote: > > > On 2015/10/15 12:26:19, Michael Achenbach wrote: > > > > > My local testing shows that if you're missing .landmines you won't get > > > > anything > > > > > clobbered. > > > > > I would guess it's by design since if you have a clean checkout, you > won't > > > > have > > > > > anything to clobber anyway. > > > > > What cases can you think of when you would like to clobber and would be > > > > missing > > > > > the .landmines? > > > > > > > > Exactly the case you have here now. Here's the timeline: > > > > > > > > 1. bot builds with checkout in state A > > > > 2. you commit the landmines support CL as B > > > > 3. you commit whatever needs a landmine as C > > > > 4. you commit a landmine as D > > > > 5. bot builds with checkout in state D > > > > > > > > It's important that the bot (in a particular slavedir) didn't build > between > > 1 > > > > and 5. The build will have the incremental difference of A and D (i.e. the > > > > checkout isn't fresh), but won't execute the clobber. With a big enough > > slave > > > > pool there is always a chance that there are some bots in that state. You > > > > won't know which until you run into. > > > > You're right. This calls for me waiting at least a day (or even more) with > > submitting my GN change that's known to break. I should ensure all bots have > run > > a build with this CL so all slaves that has the bad args.gn files in the out/ > > has gotten the chance to get a .landmines file. > > > > > > > > The probability get lower that this happens with increased time between 2 > and > > 4. > > > And each time a compile fails, compile.py nukes the out dir anyway, so it > > might > > > clean up itself... > > > > True, at least now I have a better tool than before to avoid wiping all the > > slaves. > > Doing it at a few machines is fine with me, worst case. > > Ah, and because I ran into that before, I tuned our landmines implementation a > bit: > https://code.google.com/p/chromium/codesearch#chromium/src/v8/build/landmines... > > Chromium's doesn't have this. Maybe it just should? I dunno, I guess they try to be restrictive about the clobbing but it's also likely nobody just noticed that was the behavior. I'll go ahead with this for now and see if it works. Good to be aware of the behavior at least.
Message was sent while issue was closed.
On 2015/10/15 14:20:19, kjellander (webrtc) wrote: > On 2015/10/15 12:58:51, Michael Achenbach wrote: > > On 2015/10/15 12:51:26, kjellander (webrtc) wrote: > > > On 2015/10/15 12:36:24, Michael Achenbach wrote: > > > > On 2015/10/15 12:26:19, Michael Achenbach wrote: > > > > > > My local testing shows that if you're missing .landmines you won't get > > > > > anything > > > > > > clobbered. > > > > > > I would guess it's by design since if you have a clean checkout, you > > won't > > > > > have > > > > > > anything to clobber anyway. > > > > > > What cases can you think of when you would like to clobber and would > be > > > > > missing > > > > > > the .landmines? > > > > > > > > > > Exactly the case you have here now. Here's the timeline: > > > > > > > > > > 1. bot builds with checkout in state A > > > > > 2. you commit the landmines support CL as B > > > > > 3. you commit whatever needs a landmine as C > > > > > 4. you commit a landmine as D > > > > > 5. bot builds with checkout in state D > > > > > > > > > > It's important that the bot (in a particular slavedir) didn't build > > between > > > 1 > > > > > and 5. The build will have the incremental difference of A and D (i.e. > the > > > > > checkout isn't fresh), but won't execute the clobber. With a big enough > > > slave > > > > > pool there is always a chance that there are some bots in that state. > You > > > > > won't know which until you run into. > > > > > > You're right. This calls for me waiting at least a day (or even more) with > > > submitting my GN change that's known to break. I should ensure all bots have > > run > > > a build with this CL so all slaves that has the bad args.gn files in the > out/ > > > has gotten the chance to get a .landmines file. > > > > > > > > > > > The probability get lower that this happens with increased time between 2 > > and > > > 4. > > > > And each time a compile fails, compile.py nukes the out dir anyway, so it > > > might > > > > clean up itself... > > > > > > True, at least now I have a better tool than before to avoid wiping all the > > > slaves. > > > Doing it at a few machines is fine with me, worst case. > > > > Ah, and because I ran into that before, I tuned our landmines implementation a > > bit: > > > https://code.google.com/p/chromium/codesearch#chromium/src/v8/build/landmines... > > > > Chromium's doesn't have this. Maybe it just should? > > I dunno, I guess they try to be restrictive about the clobbing but it's also > likely nobody just noticed that was the behavior. > I'll go ahead with this for now and see if it works. Good to be aware of the > behavior at least. The thing is that you might not really be aware of it not working. Random people might get random compile failures on trybots for example...
Message was sent while issue was closed.
On 2015/10/15 14:22:13, Michael Achenbach wrote: > On 2015/10/15 14:20:19, kjellander (webrtc) wrote: > > On 2015/10/15 12:58:51, Michael Achenbach wrote: > > > On 2015/10/15 12:51:26, kjellander (webrtc) wrote: > > > > On 2015/10/15 12:36:24, Michael Achenbach wrote: > > > > > On 2015/10/15 12:26:19, Michael Achenbach wrote: > > > > > > > My local testing shows that if you're missing .landmines you won't > get > > > > > > anything > > > > > > > clobbered. > > > > > > > I would guess it's by design since if you have a clean checkout, you > > > won't > > > > > > have > > > > > > > anything to clobber anyway. > > > > > > > What cases can you think of when you would like to clobber and would > > be > > > > > > missing > > > > > > > the .landmines? > > > > > > > > > > > > Exactly the case you have here now. Here's the timeline: > > > > > > > > > > > > 1. bot builds with checkout in state A > > > > > > 2. you commit the landmines support CL as B > > > > > > 3. you commit whatever needs a landmine as C > > > > > > 4. you commit a landmine as D > > > > > > 5. bot builds with checkout in state D > > > > > > > > > > > > It's important that the bot (in a particular slavedir) didn't build > > > between > > > > 1 > > > > > > and 5. The build will have the incremental difference of A and D (i.e. > > the > > > > > > checkout isn't fresh), but won't execute the clobber. With a big > enough > > > > slave > > > > > > pool there is always a chance that there are some bots in that state. > > You > > > > > > won't know which until you run into. > > > > > > > > You're right. This calls for me waiting at least a day (or even more) with > > > > submitting my GN change that's known to break. I should ensure all bots > have > > > run > > > > a build with this CL so all slaves that has the bad args.gn files in the > > out/ > > > > has gotten the chance to get a .landmines file. > > > > > > > > > > > > > > The probability get lower that this happens with increased time between > 2 > > > and > > > > 4. > > > > > And each time a compile fails, compile.py nukes the out dir anyway, so > it > > > > might > > > > > clean up itself... > > > > > > > > True, at least now I have a better tool than before to avoid wiping all > the > > > > slaves. > > > > Doing it at a few machines is fine with me, worst case. > > > > > > Ah, and because I ran into that before, I tuned our landmines implementation > a > > > bit: > > > > > > https://code.google.com/p/chromium/codesearch#chromium/src/v8/build/landmines... > > > > > > Chromium's doesn't have this. Maybe it just should? > > > > I dunno, I guess they try to be restrictive about the clobbing but it's also > > likely nobody just noticed that was the behavior. > > I'll go ahead with this for now and see if it works. Good to be aware of the > > behavior at least. > > The thing is that you might not really be aware of it not working. Random people > might get random compile failures on trybots for example... But what would be different for us compared to Chromium if we use the same script? Or do you mean only during the transition from this commit to the point where I commit the first landmine?
Message was sent while issue was closed.
Description was changed from ========== Landmines support to ease clobbering builds Landmines is a feature used in Chromium that makes it possible to clobber the build output directory when needed. Example scenarios are when compiler/tool/infrastructure changes require a full rebuild. This is mainly to ease clobbering on all bots, but will also ensure developers don't have to waste time on figuring out what's wrong (or rely on reading PSA e-mails announcing when such manual action is required). This CL depends on https://codereview.chromium.org/1407733002/ being landed and rolled into DEPS first. BUG=5077 R=kjellander@chromium.org, machenbach@chromium.org Committed: https://chromium.googlesource.com/external/webrtc/+/27576e0b68cff41d0b28cdd38... ========== to ========== Landmines support to ease clobbering builds Landmines is a feature used in Chromium that makes it possible to clobber the build output directory when needed. Example scenarios are when compiler/tool/infrastructure changes require a full rebuild. This is mainly to ease clobbering on all bots, but will also ensure developers don't have to waste time on figuring out what's wrong (or rely on reading PSA e-mails announcing when such manual action is required). This CL depends on https://codereview.chromium.org/1407733002/ being landed and rolled into DEPS first. BUG=webrtc:5077 R=kjellander@chromium.org, machenbach@chromium.org Committed: https://chromium.googlesource.com/external/webrtc/+/27576e0b68cff41d0b28cdd38... ========== |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
