In the following project
https://github.com/spark-jobserver/spark-jobserver,
we recently upgraded from 0.13.12 to 1.1.6.
In 0.13.12 we used to do sbt "testOnly *JobServerSpec" and tests cases for the specific class used to run but with 1.1.6, it is not the case anymore.
To reproduce the issue,
NOTE: If you get a Not in Gzip format exception, then in the project root, execute rm -rf **/target
clone the project, currently it is using 1.1.6.
git checkout d7e231ea4ee9981e49b411d09f132e396c901b98 will switch to a point before 1.1.6 was introduce
Execute sbt "testOnly *JobServerSpec", tests should be running
git checkout master to switch back to version with sbt 1.1.6
Execute sbt "testOnly *JobServerSpec"
It should not run any tests.
Related
Given the following state of my NextJS monorepo app:
monorepo with multiple private packages managed via yarn workspaces
develop is default branch, testing environment and has multiple commits ahead of main
main branch has fewer commits and only those ready for staging environment
commits to main are pushed via PRs with cherry-picking from develop
develop versioning of those private monorepo packages is all green (the yarn version check command)
version checking is disabled PR-level and branch level on main and due to cherry-picking/reverts/squash/etc. the yarn version check fails on the main branch with the following error:
yarn version check
➤ YN0001: UsageError: Your current branch contains multiple versioning files; this isn't supported:
- /Users/tbutcaru/Projects/my-nextjs-app/.yarn/versions/00648a82.yml
- /Users/tbutcaru/Projects/my-nextjs-app/.yarn/versions/009a6542.yml
- /Users/tbutcaru/Projects/my-nextjs-app/.yarn/versions/018f7b67.yml
- /Users/tbutcaru/Projects/my-nextjs-app/.yarn/versions/0197a805.yml
at h (/Users/tbutcaru/Projects/my-nextjs-app/.yarn/plugins/#yarnpkg/plugin-version.cjs:5:3539)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
....
the mentioned .yarn/versions/... files do not exist in my main branch.
Same issue here and here - closed without solution. I've already tried what others have said through comments in the mentioned links.
I've tried:
yarn version apply --all
yarn version check --interactive
upgrade to latest yarn 3.4.0 (using 2.4.2 right now)
deleted all .yarn/versions file dir + yarn.lock and reinstall all packages
manually bump all private packages versions
copy the .yarn/versions file dir from develop to main
added changesetIgnorePatterns: - '.yarn/**/*' in the .yarnrc.yml file and I no longer get the error above but the following YN0000: #my-nextjs-app/shared-components#workspace:packages/shared-components has been modified but doesn't have a release strategy attached and I've run the yarn version check --interactive, so the package has a release strategy attached, but still the yarn version check fails.
... none of the above worked.
How can I fix the "multiple versioning files" issue?
Or, at least, how do I completely reset/reinit the yarn workspace packages versions on the main branch?
Thank you!
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
I know how to package and then deploy meteor application. But recently for one project i'm stuck at an error which i couldn't resolve.
Steps I followed for package and deploy of my meteor app:
1. meteor build package
2. cd package
3. tar -xf inventoryTool.tar.gz
4. cd bundle/programs/server
5. npm install
6. cd ../..
7. PORT=<port> MONGO_URL=mongodb://127.0.0.1:27017/dbName ROOT_URL=http://<ip> node main.js
Here is the log for the error when i run the npm install(STEP 5) command.
Is there anything missing in my execution?. I'm not using the fibers package anywhere in my project. Does anyone have solution to this problem? Thanks in advance.
Why this happens (a lot)?
Your local version of node is v8.9.4. When using the build command, you will export your application and build the code against this exact node version. Your server environment will require this exact version, too.
An excerpt from the custom deployment section of the guide:
Depending on the version of Meteor you are using, you should install
the proper version of node using the appropriate installation process
for your platform. To find out which version of node you should use,
run meteor node -v in the development environment, or check the
.node_version.txt file within the bundle generated by meteor build.
Even if you don't use fibers explicitly it will be required to run your Meteor app on the server correctly.
So what to do?
In order to solve this, you need to
a) ensure that your local version of node exactly matches the version on the server
b) ensure that you build against the server's architecture (see build command)
To install a) the very specific node version on your server you have two options:
Option I. Use n, as described here. However this works only if your server environment uses node and not nodejs (which depends on how you installed nodejs on the server).
II. To install a specific nodejs version from the repositories, you may do the following:
$ cd /tmp
$ wget https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/nodejs_8.9.4-1nodesource1_amd64.deb
$ apt install nodejs_8.9.4-1nodesource1_amd64.deb
If you are not sure, which of both are installed on your server, check node -v and nodejs -v. One of both will return a version. If your npm install still fails, check the error output and if it involves either node or nodejs and install the desired distribution using the options above.
To build b) against the architecture on your server, you should use the --architecture flag in your build command.
I am migrating from activator from 0.13.x to sbt 1.x.
I used to compile my modules like this $ activator clean compile publish-local -Dversion=1
Now, I am trying to do it with sbt since activator has been deprecated, but I can not find how I should migrate to something similar like $ sbt clean compile publish-local -Dversion=1?
Activator (the CLI part) was just a wrapper around sbt with some custom commands. So what you wrote should work the same, expect that the snake-case was deprecated in favor of the camelCase:
sbt clean compile publishLocal
If you need to pass a var to the Java runtime with -D you have to place it before any commands: sbt -Dversion=1 ....
Notice that you use batch mode to run the commands:
Running in batch mode requires JVM spinup and JIT each time, so your build will run much slower. For day-to-day coding, we recommend using the sbt shell or Continuous build and test feature described below.
To follow this recommendation, just run sbt and then enter those commands one by one. Or to run them all sequentially, enter ; clean; compile; publishLocal.
I was wondering if SBT has something similar to the Gradle Wrapper?
I would like to use it on a CI server without having to install SBT first.
The documentation mentions a sbt-launcher, but that seems to be geared towards running actual application instead of builds.
Yes, sbt-extras is a bash script that you can commit to your repository to act like the gradle wrapper.
The sbt-extras project is centered around a stand-alone script called sbt which can be directly used to run sbt without having it on the machine first.
The script has logic to determine the proper version of sbt for the project, download the correct version of the sbt jar, and then run the tasks through sbt.
If you copy the sbt script into your project, you can simply call it — from your CI server, locally, or wherever — to run sbt tasks without needing sbt installed separately.