I have tried other solutions provided, none of them helped this exact scenario.
We have recently updated Jenkins machine to Catalina, then Jenkins from 2.5 to 2.222.1, then ruby from 2.3 to 2.6, reinstalled Cocoapods.
/usr/local/bin/pod install command fails in Jenkins CI throwing error
env: ruby_executable_hooks: No such file or directory
Remotely logged in to machine and running same command from same job folder in Terminal - all runs good with no issues
Anyone know what might be an issue?
This question answer game an idea
Error env: ruby_executable_hooks: No such file or directory while running Slather on Jenkins
This works fine
$HOME/.rvm/gems/ruby-2.6.5/wrappers/pod install
Though same fix for xcpretty doesn't seem to work. But that is for another time
Related
I've been using Cypress locally on my MacBook for some time and it's been going great. Lately my device has been having trouble, so I set up WSL on my PC so I could have a backup in case the worst were to happen.
We use yarn to handle dependencies, and I used NPM to install Cypress and Yarn.
Originally everything I was installing was going into a mounted virtual drive, where nothing was working. I eventually got it running off the linux directory, and Yarn and the dependencies installed fine. I also was able to install Cypress#9.5.4, which is the current version I'm using.
Every time I try to run Cypress headed or headless, I'm being met with the following:
No version of Cypress is installed in: /home/workterminal/.cache/Cypress/9.5.4/Cypress
Please reinstall Cypress by running: cypress install
----------
Cypress executable not found at: /home/workterminal/.cache/Cypress/9.5.4/Cypress/Cypress
----------
A couple coworkers took a stab at it, and this is as far as we could get before I decided to reach out for help here. We got me off the mounted virtual drive, we got NPM and Yarn installed properly after using the linux directory, and then reinstalled Cypress using yarn add cypress#9.5.4, which completed successfully.
We've tried expanding $PATH to include everywhere where Cypress exists, but it always looks in .cache. What can I do to toubleshoot further?
So I am having some issues with vagrant. I had initially tried to report this as an issue on the vagrant github issue boards, but they kept closing the issues without responding to them. I guess they decided I wasn't worth their time, or they were just behaving unprofessionally. Anyway, Here is the problem: I use vagrant with virtualbox, and a new version of virtualbox was recently released that is, unfortunately, not compatible with the latest vagrant installation.
However, the people at hashicorp have already updated the source code so that it is compatible with the new version of virtualbox, but you have to build the vagrant executable from the source repo (instructions here). So I followed the instructions and vagrant is working just like it used to.....when the only command I need to run is vagrant up. I should also mention ahead of time that, in order to run the vagrant dev build, the current working directory needs to be the root of the source code repo and the dev build can only be run using the following command with ruby:
bundle exec vagrant
With that being said, I needed to update one of my custom boxes, so I built a vm in the updated version of virtualbox and ran the below command
bundle exec vagrant package --base go --vagrantfile ../../vagrant/vagrantfile
After an extended period of time, vagrant spat back out the following error
The executable 'bsdtar' Vagrant is trying to run was not found in the %PATH% variable. This is an `error. Please verify this software is installed and on the path.`
I should also note that I use a windows machine and that this error never occurred when using the installed version of vagrant. At this point, I had posted the issue on github to get some input from the devs, but they (very unprofessionally) decided to ignore my requests for help and close the issues without providing any response. I used the GNUwin32 project to make numerous unix commands available to my Windows environment and added the folder to my PATH environment variable. I then run the same command again to create my new box and it works!! So then I upload it to the vagrant cloud and attempt to update the vagrant box that is stored on my system by running the following command:
bundle exec vagrant box update
Then, after waiting for a while, vagrant then spat this error out at me:
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and that enough disk space
is available and then try again.
The output from attempting to unpackage (if any):
C:\gnuwin32\bin/bsdtar.EXE: invalid option -- s
Usage:
List: bsdtar.EXE -tf <archive-filename>
Extract: bsdtar.EXE -xf <archive-filename>
Create: bsdtar.EXE -cf <archive-filename> [filenames...]
Help: bsdtar.EXE --help
Another error, and still involving this bsdtar tool. It does not appear that anyone else is reporting the issue I am running into because I think they are just waiting for hashicorp to release the new official installation, but, just to give you a look into their priorities, the version of virtualbox that was released which no longer worked with vagrant was released back on December 10. It has been over a month since and there is still no updated release.
So, I am hoping that someone out there might be able to find out why I keep running into these errors when trying to use vagrant's dev build and provide a solution. If not, then maybe if someone else is able to reproduce the issue and report it to hashicorp, maybe they will listen to someone else.
If you are on Ubuntu 20.04 then bsdtar was removed. Try to install libarchive-tools package.
$ sudo apt-get install libarchive-tools
I figured it out. My original hypothesis was correct: since vagrant is a tool that was built primarily to be run on linux machines, then vagrant runs in windows, the installation includes a mingw environment with all of the dependencies vagrant needs to function and which the installed vagrant executable imports into the console session when run. This why the dev build kept failing: because it was not importing this mingw environment. So, in order to fix the issue, I first cloned the vagrant source code repo from github and followed the instructions I linked to above to build the executable from the source repo. I then copied all of the files in the source repo into the following folder:
<hashicorp install folder root>\Vagrant\embedded\gems\2.2.6\gems\vagrant-<version num>
So, for me, the destination directory is C:\HashiCorp\Vagrant\embedded\gems\2.2.6\gems\vagrant-2.2.6
This directory is identical to the source code repo, and copying the source code repo to the above folder replaces the installation version of vagrant with the dev build. After I did this, running the vagrant commands which had failed previously normally (as in, without using ruby or bundle) worked. I hope this helps someone else out there who Hashicorp has decided is not worth their time.
I'm having a very strange issue:
Working on a project, which is a monorepo managed with lerna, I am unable to run tests for some reason unless I use sudo. I know it is not a project configuration issue, because no one else on my team is experiencing this problem.
The error, which is thrown immediately, ends up being:
Jest encountered an unexpected token
...
/Users/jasmar/dev/project/src/__setup__/setupTest.js:1
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import { configure } from 'enzyme';
My environment is:
Mac OS X High Sierra
yarn (installed via brew)
Node 8.10.0 (via nvm; installed via curl)
I am an admin on the machine and have run sudo chmod -R ug+w . against the project directory to no avail.
I've also tried npm run test to no avail.
The test script that yarn runs is FORCE_COLOR=1 lerna --concurrency=4 run test and I have tried dropping concurrency to 1.
While running sudo yarn test does work, it is problematic as it generates new snapshots with incorrect permissions and makes managing version control extremely difficult.
Any ideas would be hugely appreciated.
Thanks!
remove the underscores for SetUp
I've got problem with heroku pg:backups capture --app myapp command.
Heroku CLI submits usage information back to Heroku. If you would like to disable this, set `skip_analytics: true` in /home/ubuntu/.heroku/config.json
heroku-cli: Updating to 4.99.0-e5f5ef4... done
heroku-cli: Updating CLI...heroku-cli: Updating to 5.11.8-f58f4fa... done
Starting backup of postgresql-spherical-5948... done
Use Ctrl-C at any time to stop monitoring progress; the backup will continue running.
Use heroku pg:backups:info to check progress.
Stop a running backup with heroku pg:backups:cancel.
Backing up DATABASE to b598... pending
Backing up DATABASE to b598... !
▸ MODULE_NOT_FOUND: Cannot find module 'bytes'
Does anybody have similar problem? This command is launched with deploy on CircleCI.
I started running into the same problem yesterday and was finally able to come up with a solution that is working for me.
For starters, it looks like bytes is a dependency of heroku-pg, which is the part of Heroku CLI that is being used for the backups command. It seems like the dependency is not being included or installed with the version of heroku-cli that is being used to run the backup command.
I tried CircleCI’s “Rebuild with SSH” to troubleshoot the issue, and encountered similar error messages when attempting the backup command there. While trying to reinstall heroku-cli using npm, I found that the npm and node versions were way behind what heroku-cli wanted, so maybe that is part of the problem? Anyway, reinstalling with npm only produced an even more broken Heroku CLI.
Finally I checked the build environment and it was set to Ubuntu 12.04 (Precise) which probably explains the way out of date npm/node packages. I changed it to Ubuntu 14.04 (Trusty) and pushed a new commit to CircleCI (A rebuild alone is not sufficient to change OS versions) and was able to successfully run the backup command that had been failing!
Solution: Set CircleCI build environment to Ubuntu 14.04
I get this error when I run my cucumber tests:
"*Unable to either launch or connect to Chrome. Please check that ChromeDriver is up-to-date. Using Chrome binary at: /opt/google/chrome/google-chrome (Selenium::WebDriver::Error::UnknownError)
*"
I downloaded the chromdriver, unzip it, copy it to the path (/opt/google/chrome/google-chrome ) and sudo chmod +x /opt/google/chrome/google-chrome.
which google-chrome : /usr/bin/google-chrome
which chromedriver : /usr/share/ruby-rvm/gems/ruby-1.9.2-p318/bin/chromedriver
capybara (1.1.2)
cucumber (0.9.4)
cucumber-rails (0.3.2)
selenium-webdriver (2.20.0)
I searched my error but none of the answers worked for me!
When I run my test I do not see chrome starts!
I really dont know what is wrong! I tried two different versions of chromedriver!
Jenkins should run/executes my tests in CI.The tests work when you run them but not when Jenkins runs them? I could run them by another user and then I installed jenkins and I get this error. I get the same error when I run my tests in terminal at terminal as well.Did you read https://wiki.jenkins-ci.org/display/JENKINS/My+software+builds+on+my+computer+but+not+on+Jenkins ? I couldnt find much about my problem here. xvfb: I installed the plugin in the jenkins but in the build environment if I click "run xvfb before the build and shut it down after", I get this error: "FATAL: null java.lang.NullPointerException"
Please provide more details. How does this question relate to Jenkins? Is Jenkins executing the tests? The tests work when you run them but not when Jenkins runs them? You do not go so far as to say that out loud, but I will assume it because it is what people usually need help with.
Did you read https://wiki.jenkins-ci.org/display/JENKINS/My+software+builds+on+my+computer+but+not+on+Jenkins ?
If you are executing Chrome inside a Jenkins job, do you have something like https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin or https://wiki.jenkins-ci.org/display/JENKINS/Xvnc+Plugin installed?
chromedriver can be installed in two ways: downloading, decompressing the zip and putting the file in "/usr/bin" or adding the "chromedriver-helper" gem in your Gemfile.
Choose one or another way because doing both many time it causes problems. If you are installing chromedriver from google, be sure to uninstall the gem:
gem uninstall chromedriver-helper
and be sure chromedriver is in your path:
which chromedriver
Give this a try instead => https://github.com/flavorjones/chromedriver-helper
Finally I found the answer:
if you want to run GUI tests on Jenkins CI running on Windows do not
configure it as a windows service instead run it from the command
prompt or set it up as a scheduled task to run on windows logon using
the command “java -jar jenkins.war”
taken from this article