Gibson Fahnestock

I seem to remember discussing this with @gdams , it's certainly something that I'd like to do if possible, if we could get it to work it would be really...

Starting with what we have in core makes sense, it also means any changes we make can then easily be added to core if necessary.

@phillipj https://github.com/nodejs/citgm/pull/394#issuecomment-294244848 this is very cool. One question, at the moment the bot says: >@gibfahn build started: https://ci.nodejs.org/job/citgm-continuous-integration-pipeline/ It'd be cool if it had the build number as well, so...

@MylesBorins I'd be interested to know your thoughts on this. I'm +1 on this. If we can encourage module authors to update their modules here then that would be an...

>The whole point of citgm is to find failures >the whole point of citgm is that we catch module failures as soon as they are released I disagree pretty strongly...

>When I run CITGM on a release I care that we are testing against what people will get when they run npm install. That is whatever the latest version of...

> I am not convinced that we would keep the lookup table up to date and am concerned that it would fall back on me to maintain it. Yeah, this...

>would you propose we keep the lookup updated? Ideally we'd have >How do we handle lkgr being different across release lines and platforms I can definitely see that snowballing out...

>Wanted to double check. Did you mean for your "after" to be: Whoops, yes my bad, you'd still specify `env`. I updated the original example to match your correction. >...

>In thinking about this, maybe it could be worthwhile to add this to the builder API. Adding this to the builder API would basically mean that `#[clap(env)]` would call something...