Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Daniel Byrne
    @danwbyrne
    What is the recommended flow for excluding src/gulpfile/tsconfig/tslint files from publishing using rush publish?
    Ian Clanton-Thuon
    @iclanton
    @danwbyrne - you want to drop a .npmignore file in your projects' roots. Ours take a conservative approach of ignoring everything and then selectively un-ignoring things we specifically want to publish. Take a look here: https://github.com/microsoft/rushstack/blob/master/apps/rush/.npmignore
    Daniel Byrne
    @danwbyrne
    this is just what I was looking for ty :)
    Ian Clanton-Thuon
    @iclanton
    Glad I could help :)
    Josh Biddick
    @sadsa
    Good morning! Does rush have the ability to specifify both projects that publish to NPM and those that do not (i.e. they follow the publish workflow, generate changelogs and bump versions but don't publish to NPM)?
    Ian Clanton-Thuon
    @iclanton
    You can create multiple version policies, and then use the --pack flag with one of them to generate tarballs instead of publishing to a package feed
    Josh Biddick
    @sadsa
    You mean to say - target a specific version policy when running rush publish?
    Ian Clanton-Thuon
    @iclanton
    You'll want to use the --version-policy argument
    Josh Biddick
    @sadsa
    Cheers mate, I'll give that a go!
    Pete Gonzalez
    @octogonz
    😮 Gitter is proposing to deprecate all their apps except for the web page? gitlab-org/gitter/webapp#2281
    sunilsurana
    @sunilsurana
    Hi,
    We have a rush based big repository. On one of the pool of VM's in our datacenter the rush install takes 8 minutes and on another pool of machine(On Azure) it takes 14minutes. This is consistent. Both the pools are in same city. The registry is pointing to office.pkgs.visualstudio.com
    The time to checkout source code which is also from office.visualstudio.com is same on both pool around 3 minutes. I am not able to figure out what can be the issue. The rush verbose logs are extremely huge and find it difficult to make meaning out of it.
    Is there any way we can debug this?
    William Bernting
    @wbern
    Just a random thought, could it be IO related?
    sunilsurana
    @sunilsurana
    Yes it can be but then shouln't checkout should also be slow
    Even if lets say IO is slow are there any tips to improve rush install. One option what i can think of is figure out the upstream and downstream affected packages in PR build and modify rush.json to only retain those packages and then do rush install.
    Other is to setup local npm server
    Pete Gonzalez
    @octogonz
    Does your CI job start with a clean VM each time? For an internal machine pool, it's highly recommended to preserve the machine state between jobs.
    sunilsurana
    @sunilsurana
    Most of the time its clean VM. But lets say if i fix the VM's then how can i improve
    Pete Gonzalez
    @octogonz
    Well by itself, that should cut your typical rush install down to like 10 seconds heheh
    ALso, are you in North America? 14 minutes is extremely long. Typical max time in Redmond is like ~5 mins on a slow day.
    sunilsurana
    @sunilsurana
    Ok i will try that. I thought PR build will always do fresh git clone and checkout
    Pete Gonzalez
    @octogonz
    It does for GitHub because PRs do not come from trusted users. But if your repo is only used by employees, it is highly recommended to preserve the VM state.
    HIGHLY heheh
    sunilsurana
    @sunilsurana
    and lets say if there is change in shrinwrap file then will rush install work on updated file. Will it figure out the new dependencies
    Pete Gonzalez
    @octogonz
    It will, reliably, and wayyy faster than clean install
    sunilsurana
    @sunilsurana
    Thanks I will try this approach
    Pete Gonzalez
    @octogonz
    :thumbsup:
    Also, hi Sunil! 😁
    sunilsurana
    @sunilsurana
    Hello Pete :). Hope you are doing good.
    and for improving build and test i am thinking for build figure out all the affected packages and their upstream and downstream packages and build a list. Then do rush build --to pkg1 --to pkg2 (where pkg1,pkg2 are all packages in list)
    FOr test figure out all the affected packages and just test affected packages and downstream packages "rush test -f pkg1 -f pkg2"
    William Bernting
    @wbern
    @octogonz this should be reflected better in the ci docs btw. Some of my PT guys thought rush rebuild was the only recommended way.
    Pete Gonzalez
    @octogonz

    i am thinking for build figure out all the affected packages and their upstream and downstream packages and build a list. Then do rush build --to pkg1 --to pkg2 (where pkg1,pkg2 are all packages in list)

    We discussed this recently :point_up: October 19, 2019 9:27 PM

    William Bernting
    @wbern
    Oh yeah.
    My team is using docker images still, seems to be working for a few weeks despite my absence
    I think it's good enough to recommend to others at this point
    Pete Gonzalez
    @octogonz

    this should be reflected better in the ci docs btw.

    I opened microsoft/rushjs.io-website#43

    William Bernting
    @wbern
    The only downside is that if your ci workers don't preserve workspaces for any amount of time, you'll always have to do a docker pull on the pre-existing image, which is better as a long-term caching mechanism rather than a short one
    sunilsurana
    @sunilsurana

    It does for GitHub because PRs do not come from trusted users. But if your repo is only used by employees, it is highly recommended to preserve the VM state.

    Will checkout how the behavior is for Azure Devops pipelines

    William Bernting
    @wbern
    Good stuff. I'm gonna document the docker approach to that issue when I'm back at work. I think it has several upsides.
    Pete Gonzalez
    @octogonz
    :thumbsup:
    Steve Dalonzo
    @sdalonzo
    i see a year old issue without much movement - is there any ongoing effort to support pre/post hooks in package.json? rushx build in a project runs my prebuild script, rush build does not. microsoft/rushstack#830
    Pete Gonzalez
    @octogonz
    The maintainers don't have a strong incentive to work on this, since we use a tool chain. Those pre/post tasks can be (and would best be) solved via the tool chain. Shell scripts are clumsy and not very portable between OS's.
    But this issue makes sense, and is big enough gap that we classified it as a "bug". Looks like we also marked it as "effort: easy". Would you want to work on it?
    Steve Dalonzo
    @sdalonzo
    if i can find the time, i'd be willing to. right now i'm up to my eyeballs in the PoC making the case for using rush at my org
    Steve Dalonzo
    @sdalonzo
    and i'd have to get around to learning some typescript, which probably isn't the worst thing :P
    Pete Gonzalez
    @octogonz

    You might think about this bandwagon, though. When you have hundreds of projects in a repo, it can be clumsy to copy+paste huge "scripts" blocks into the package.json file for each project. Those scripts difficult to maintain, and they can't do proper logging or parameterization or command-line help. Ideally it should be:

      "scripts": {
       "build": "./bin/my-toolchain build"
      }

    ...but you can get started with:

      "scripts": {
       "build": "node ./build.js"
      }

    Writing your toolchain in a real programming language is much more scalable.

    Steve Dalonzo
    @sdalonzo
    that's a fair point
    sunilsurana
    @sunilsurana
    I see a very weird issue on Azure devops agent. When i do normal rush install and rush build on my dev box it takes 6 minutes and 4 minutes respectively. I have registered my machine as agent and if i trigger rush install and rush build from build definition it takes 9 minutes and 7 minutes respectively. not sure if its something to do with npm or agent issue. Will look into this more. Just posting here if by chance anyone else have faced similar thing
    William Bernting
    @wbern
    @sunilsurana it is 95% likely to be something other than rush. Rush devs work hard to give you deterministic results, and if there is something wrong, it really shouldn't affect both the install step and any additional steps. But still, if you find a repro, or more information, don't hesitate to share more with us!
    Pete Gonzalez
    @octogonz
    Is the agent using the ADO proxy, whereas the dev box talks directly to the npmjs registry? The proxy can be fairly slow when the cache is initially being populated, but it should be fast once it's set up
    sunilsurana
    @sunilsurana
    Hi @wbern I'm not saying its because of Rush. I believe the agent process is consuming lot of cpu. Just posted here in case if anyone had already saw and resolved this. I see that cpu utillization going upto 100%. I'll be following up with Az devops team on this. Thanks
    Pete Gonzalez
    @octogonz
    (@sunilsurana Are you using the hosted VM that comes free with ADO? Those boxes are underpowered and mainly intended for running simple scripts. IIRC 1ES CloudBuild maintains a lab with fast VMs that you can use. @iclanton can help get you set up.)