I am using Yarn 1.21, and with a couple of manual steps I am able to make the offline mode work in a completely offline environment (corporate network).
Yarn 2 looks very exciting but after some googling I cannot find any mention of this.
Also looking through the Yarn 2 docs I can't see any mention of an offline mode.
Does Yarn 2 support an --offline mode?!?
I found out that Yarn 2 will support an offline mode, which is referred to as the Yarn cache, from this answer below thanks to arcanis:
the offline mirror has been merged with the Yarn cache,
so any time you see the word "cache" you can think of it
as what was previously called the offline mirror
https://github.com/yarnpkg/yarn/issues/7872#issuecomment-582385100
Related
In a yarn workspace project I want to make yarn #workspace/name add lodash use the range of lodash that is already in use in another workspace (if so) else it should pull in latest as per usual. I've hoped yarn constraints would solve this but they only seem to cover the enforcement bit - e.g. yarn add installs latest and then yarn constraints will fail checks.
I am trying to find out how to deploy a hadoop cluster using ambari by using apache big top
According to the latest release bigtop 1.5:
https://blogs.apache.org/bigtop/
my understanding is that Bigtop Mpack was added as a new feature, that enables users to
deploy Bigtop components via Apache Ambari.
I am able to install the Bigtop components via command line, but do not find any documentation on how to install these bigtop hadoop components via ambari.
Can someone please help redirect me into some documentation that tells me how to install various hadoop components(bigtop packages) via ambari?
Thanks,
I'm from Bigtop community. Though I don't have a comprehensive answer. The Bigtop user mailing list had a discussion recently that has several tech details can answer your question:
https://lists.apache.org/thread.html/r8c5d8dfdee9b7d72164504ff2f2ea641ce39aa02364d60917eaa9fa5%40%3Cuser.bigtop.apache.org%3E
OTOH, you are always welcome to join the mailing list and ask questions. Our community is active and happy to answer questions.
Build a repo of Big Top
To install that repo with Ambari, you have to register the stack/version. You will need to create a version file. I found an example of one here.
Complete installation like you would with a normal build
This is highly theoretical (..haven't done this before..) I have worked with a BIGTOP Mpack before that took care of some of this work but it's not production ready yet, and works with an old version of Ambari, not the newest. (I was able to install/stop/start HDFS/Hive). These instruction above should work with any version of Ambari.
I have been able to test Matt Andruff's theory with a VM. Here was my process and where I stopped;
Built a repo of Apache BigTop 1.5.0
Built BigTop using Gradlew
Installed Apache Ambari 2.6.1 on my system
Enabled BigInsights build version xml file and modified the package version numbers to match my Bigtop build
Note: You can also build your own version file if you want as Matt mentioned
Setup a webserver to host your package repo
Point your xml version file repo to your local webserver for packages
From there you can complete the installation of your packages as you would normally.
I have only done this with a single VM thus far and will be trying to spin up a small cluster using AWS in the coming weeks.
My team is developing a React component library which relies on MaterialUI components. The customer of our employer wants to automatically signal and/or upgrade outdated dependencies (specifically when the dependency on MaterialUI becomes outdated at least). We are using yarn as dependency manager.
I found yarn lists all the outdated dependencies (or a specific dependency if specified) through the yarn outdated command. One can then upgrade said dependencies using the yarn upgrade command to which the dependency to be updated is supplied as parameter. To do this using a single command, running yarn upgrade-interactive lists outdated dependencies which the user can then select to be updated.
I am wondering if there is/are way(s) to automate this process. I tried piping the results of yarn outdated to yarn update as well as yarn version, but yarn upgrade seems to ignore whatever input it receives and updates every package regardless and yarn version throws errors saying the version are not proper semvers.
I realise yarn upgrade-interactive makes this process easy and quick for developers, however the project is intended to become open-source over time and the customer prefers a centralised solution rather than relying on every individual contributor to track this themselves. As far as I am aware, yarn upgrade-interactive cannot be automated as it requires user input in order to select the package(s) to be updated.
Other solutions I found, such as Dependabot or packages like 'yarn-outdated-notifier', seem to only work with GitHub. The project is currently running on Azure DevOps and, when it goes public, will run on GitLab.
Is there any way we could do this in our CI/CD environment or with any (free) solutions? The customer prefers to have as few dependencies as possible.
I'm trying to setup a mono repo and came across lerna+yarn. My problem is, what is the actual advantage I get in using lerna. I can use yarn workspaces only and have the same functionality. I came across the following Are there any advantages to using Lerna with Yarn workspaces? but here there is no specific answer as to the specific advantage of using lerna.
as stated in the yarn workspaces documentation,
workspaces are the primitives that tools like lerna can use
You might have a project that only needs workspaces as "primitives", and not lerna. Both are tools, but lerna as a higher-level-tool than yarn workspaces helps you organize your monorepo when you are working on open source or in a team:
The install (bootstrap) / build / start-scripts are at the project root:
meaning one install and package resolution instead of one for each package
node_modules at the root is 'fat', in sub-projects it's tiny: One place to look for when you resolve package conflicts
parallel execution of scripts in sub-projects: E.g. starting up both server and frontend development in watch-mode can just be one command
publishing and versioning is much easier
There is certainly a lot of overlap between the two. The big difference is that Lerna handles package management, versioning and deployment.
I am using TeamCity 8.1.3 and have one task in the build queue and compatible enabled agent.
In "Build Queue" teamcity says that task "Can run on" - "2 agents"
Both agents are idle.
I tried to reinstall teamcity, reinstall buildAgent and install agent on another machine.
Tried to run agent as root. I read all agent logs and didn't find any errors; only warnings for not installed VCS tools (i need only git and its installed - no warning for it).
Why wont the agent run my task?
If the VCS tools aren't installed then TeamCity can't pull down your code and run the agent.
From the TeamCity documentation http://confluence.jetbrains.com/display/TCD8/Git+(JetBrains):
Git support in TeamCity is implemented as a plugin. Git needs to be installed on the server machine and, if the agent-side checkout is used, on the agents.
and
[Build configuration] will run only on the agents where git was detected or specified in the agent properties.
So you need install git.
This page covers installation instructions for Windows, Linux and Mac: http://git-scm.com/book/en/Getting-Started-Installing-Git. This SO post discusses installation as well: Git for beginners: The definitive practical guide
I can see two possible reasons
One of the implicit requirements not fulfilled. You need to check the enqueued build info for this, it tells why exactly the build is in the queue with compatible agents but not running. Examples can be: limitation on simultaneous builds in build or template configuration, shared resources unavailable etc. This would be listed in the little popup next to the enqueued build label
I've seen this happening when a requirement wasnt fulfilled initially (I had build configuration limited to 1 build at a time) when the build was enqueued, then it was corrected but the queue cached this requirement. Re-enqueuing the build sorted that.
Hover by mouse cursor to your VCS engine (e.g. git) and maybe you'll see there this message:
Changes have not been collected yet
In that case check performance of your TC and vcs server. (this I just guess from the message)