Based on the Readme here https://github.com/capistrano/capistrano/blob/v3.6.0/UPGRADING-3.7.md
Updating the Gemfile and running bundle install works correctly. However,
removing the :scm variable from deploy.rb and adding
require "capistrano/scm/git"
install_plugin Capistrano::SCM::Git
to the Capfile produces the following error:
cap aborted!
LoadError: cannot load such file -- capistrano/scm/git
Looking at the repo and the available branches, I'm not seeing any directory for /scm and subsequently no git.rb file other than in the main /lib/capistrano/ directory.
Am I missing something here or is this a bug with the current master branch?
Thanks,
Vincent
Had this issue in a project that hasn't been updated in a while. Upgrading capistrano solved the issue.
bundle update capistrano
Related
I have a SwiftPM issue which is driving me nuts.
Let’s say I have swift package project (no Xcode project involved). And let’s call it SDK from here. The SDK is laying in its own git repository.
So I want to build a Showcase App for that SDK by adding the SDK as a dependency, managing swift packages via Xcode not via a Package.swift file. The showcase is deployed to our QA team and they should be able to always test the latest development version of the SDK with that showcase.
So naturally I would configure the package dependency in Xcode by defining the branch develop.
So now, when I change something inside the SDK, push it onto the develop branch, and want to have that change available inside the showcase, I simply need to right click on the package inside the showcase and click Update Package and this works great.
Here comes the catch: This approach does not work on our Jenkins CI. I don’t know what I’m doing wrong here, but the xcodebuild command line tool won’t notice something changed on the develop branch of the SDK and would checkout the older revision.
What I tried so far:
I removed Package.resolved from git index and added it to .gitignore so after the git clone/checkout there should be no Package.resolved file
I removed ~/Library/Cache/org.swift.swiftpm and ~/Library/org.swift.swiftpm prior to the build
I am deleting any previously created workspace of the Jenkins Build Job prior to each build
We’re using Fastlane and so I am also explicitly setting the cloned source packages path to something inside my workspace to make sure the cloned sources are deleted on workspace clean-up via cloned_source_packages_path: "SourcePackages"
The generated xcodebuild command by Fastlane looks like this: $ xcodebuild -resolvePackageDependencies -scheme ScannerShowcase -project ScannerShowcase.xcodeproj -configuration Release -clonedSourcePackagesDirPath SourcePackage
The Fastlane gym summary looks like this:
I'd expect that if I delete all that cached packages and not having any Package.resolved file present xcodebuild would resolve the swift package to the latest revision available. Instead it seems there still is something cached somewhere and xcodebuild is using that cache.
Nothing worked so far. Does anybody have experienced this same issue and is able to provide any suggestions and/or help?
As it turns out there seems to be now way to achieve the same results with xcodebuild command line tool as with Xcode's Update Package or Update to Latest Versions.
The command line tools rely on data stored inside derived data while updating packages. Thanks to Gregory Higley's answer here I was able to solve the issue by deleting the derived data for that specific build job by
Keeping Showcase.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved out of git index,
adding Package.resolved to .gitignoreto keep it that way,
and adding the following stage to the declarative pipeline inside the Jenkins file:
stage('Clean up') {
steps {
script { env.DERIVED_DATA_PATH=sh(returnStdout: true, script: "xcodebuild -showBuildSettings | grep -m 1 BUILD_DIR | grep -oE \"/.*\" | sed 's|/Build/Products||'") }
echo "Derived data path is: ${env.DERIVED_DATA_PATH}"
// The above will return a folder with a name like /Users/you/Library/Developer/Xcode/DerivedData/MyProject-ehdkocavaenextdcrsaszjdmyssx
sh script: "rm -rf ${env.DERIVED_DATA_PATH}", label: "Removing derived project data ..."
}
}
Any other step I mentioned when asking the question wasn't necessary to achieve my goal:
No need to remove ~/Library/Cache/org.swift.swiftpm nor ~/Library/org.swift.swiftpm
No need to delete any prior created workspace on the build node
No need to to explicitly specify the SPM cloned source packages path via Fastlane with. cloned_source_packages_path: "SourcePackages"
Again big shout out to Gregory Higley for their approach.
We've recently switched from greenkeeper to dependabot for our dependencies checks and we noticed that dependabot is opening PRs changing only package-lock.json leaving package.json as it was.
On the other hand, greenkeeper, was committing changes to both files.
What is going on? Is it normal or we missed something in the settings?
This is a very late reply. We had this working in production for a long time now, but I see there's still interest prompting me that maybe people need some help. So, here it is:
When using GitHub dependabot (not dependabot-preview, although the conf file might be the same, actually):
create a dependabot.yml file in your repo's .github directory.
specify a versioning-strategy of increase.
It will look something like this (e.g. npm):
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
# Always increase the version requirement
# to match the new version.
versioning-strategy: increase
That's it. Now, package.json and package-lock.json are both written to with a version increase.
Something similar happened to me, it can be for two things:
In the dependendabot configurations you only have to accept updates for package-lock.json
(This was the one that worked for me) in the package.json in the key Name you may have written with incorrect symbols in my case I had web-app the symbol - caused me not to update it and now I have it as webapp.
The goal of the file package-lock.json is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers.
reference link is here
So package.json and package-lock.json have different purposes.
There is no error on dependabot trying to push just a modified package-lock.json.
I am using the amazing plugin sbt-ci-release but I think I am doing something wrong. I posted the whole details of all my experimentation and steps and attempt as an issue in their repo which can be find here.
To do it short, when travis is calling +publishSigned it is yelling about
java.lang.IllegalStateException: No staging repository is found. Run publishSigned first
When I tried to manually create a staging folder, it succeed without exception but did not deploy any binary and deleted the folder.
I am not sure what to try next.
Thanks.
The issue was that my branch tag was 0.1 instead of v0.1 , adding the heading v solve the problem.
See https://github.com/olafurpg/sbt-ci-release/issues/44#issuecomment-503087541
I'm using a module for my angular app called angular-translate. However, I've had to make a few small modifications to the source code to get everything working the way I'd like, and now I want to persist those changes on npm install. A colleague suggested that I fork the repo of the source code and point to my forked repo as a dependency, which I've tried in these ways, e.g.
npm install https://github.com/myRepo/angular-translate
npm install https://github.com/myRepo/angular-translate/archive/master.tar.gz
The first gives me a directory like this with no build. Just a package.json, .npmignore, and some markdown files
-angular-translate
.npmignore
.nvmrc
CHANGELOG.md
package.json
etc
The second npm install gives me the full repo, but again I don't get a build like when I use the command npm install angular-translate. I've seen some dicussion of running the prepublish script, but I'm not sure how to do this when installing all the modules. I've also tried publishing the fork as my own module to the npm registry, but again I get no build, and I'm not sure that's the right thing to do...
I apologise for my ignorance on the topic. I don't have a huge amount of experience with npm. Would love to get some feedback on this issue. It seems like it could be a common enough issue when modifications need to be made to a package's source code? Maybe there's a better solution?
Try npm install <ghusername>/<repoName>, where <ghUsername> is your GitHub username (without the #) and <repoName> is the name of the repository. That should correctly install it. You will most likely want to use the --save or --save-dev flag with the install command to save dependency in your package.json.
If that isn't working correctly, check the contents of your .npmignore file.
Don't panic if the install command takes a long time; installing from a git repository is slower than installing from the npm registry.
Edit:
Your problem is that in your case, dist/ is not committed to the repo (since it is in the .gitignore). That is where the actual code lives. dist/ is built from the files in src/ before the package is published to the npm registry, but dist/ is never committed to the repo.
It's ugly, but in this case you will have to remove dist/ from the .gitignore and then run:
npm run build
git add .
git commit
git push
(Ensure that you have run npm install first)
You then should be able to install from github.
There might be another way to do this using a prepare script, but I'm not sure if that's possible; I've never tried it. Edit: Cameron Tacklind has written an excellent answer detailing how to do this: https://stackoverflow.com/a/57829251/7127751
TL;DR use a prepare script
and don't forget package.json#files or .npmignore
Code published to npmjs.com is often not what's in the repository for the package. It is common to "compile" JavaScript source files into versions meant for general consumption in libraries. That's what's usually published to npmjs.com.
It is so common that it's a feature of npm to automatically run a "build" step before publishing (npm publish). This was originally called prepublish. It seems that Npm thought it would be handy to also run the prepublish script on an npm install since that was the standard way to initialize a development environment.
This ended up leading to some major confusion in the community. There are very long issues on Github about this.
In the end, in an effort to not change old behavior, they decided to add two more automatic scripts: prepublishOnly and prepare.
prepublishOnly does what you expect. It does not run on npm install. Many package maintainers just blindly switched to this.
But there was also this problem that people wanted to not depend on npmjs.com to distribute versions of packages. Git repositories were the natural choice. However it's common practice to not commit "compiled" files to git. That's what prepare was added to handle...
prepare is the correct way
If you have a repository with source files but a "build" step is necessary to use it,
prepare does exactly what you want in all cases (as of npm 4).
prepare: Run both BEFORE the package is packed and published, on local npm install without any arguments, and when installing git dependencies.
You can even put your build dependencies into devDependencies and they will be installed before prepare is executed.
Here is an example of a package of mine that uses this method.
Problems with .gitignore
There is one issue with this option that gets many people.
When preparing a dependency, Npm and Yarn will keep only the files that are listed in the files section of package.json.
One might see that files defaults to all files being included and think they're done.
What is easily missed is that .npmignore mostly overrides the files directive and, if .npmignore does not exist, .gitignore is used instead.
So, if you have your built files listed in .gitignore, like a sane person, and don't do anything else, prepare will seem broken.
If you fix files to only include the built files or add an empty .npmignore, you're all set.
My recommendation
Set files (or, by inversion, .npmignore) such that the only files actually published are those needed by users of the published package. Imho, there is no need to include uncompiled sources in published packages.
Original answer: https://stackoverflow.com/a/57503862/4612476
Update for those using npm 5:
As of npm#5, prepublish scripts are deprecated.
Use prepare for build steps and prepublishOnly for upload-only.
I found adding a "prepare": "npm run build" to scripts fixed all my problems.
Just use the command npm install git+https://git#github.com/myRepo/angular-translate.git. Thanks.
To piggyback off of #RyanZim's excellent answer, postinstall is definitely a valid option for this.
Either do one of the following:
Update the package.json in your forked repo to add a postinstall element to scripts. In here, run whatever you need to get the compiled output (Preferred).
Update your package.json, and add a postinstall that updates the necessary directory in node_modules.
If you've forked another persons repository, then it might be worth raising an issue to illustrate the issue that installing their package through GitHub does not work as it does not provide the necessary means to build the script. From there, they can either accept a PR to resolve this with a postinstall, or they can reject it and you can do #2.
If you are using yarn like me. Imagine that you want to use a package like this:
yarn add ghasemikasra39/gridfs-easy --save where the ghasemikasra39 is the username and gridfs-easy is the name of the repo
I try to work on a yeoman project with a team. After generating the angularjs code with > yo angular and pushed the folder to github
git add .
git push
git commit origin master
and when I clone the code from git github I have this error
Fatal error: Unable to find local grunt.
If you're seeing this message, either a Gruntfile wasn't found or
grunt hasn't been installed locally to your project. For more
information about installing and configuring grunt, please see the
Getting Started guide:
http://gruntjs.com/getting-started
so I deleted every thing from .gitignore and pushed everything again, I had this warning
The file will have its original line endings in your working
directory.
So I am quite sure it's not going to work and it's not the best way to do it. Can someone help me on how to upload the yeoman project ?
I think that angular generator for Yeoman already creates a package.json file with grunt defined as dependency along with all its task. So the correct way to compile a project after the clone is to install all npm dependencies locally using:
npm install
then run grunt to compile everything:
grunt
Of course you must have grunt-cli globally installed, which is used to run grunt locally. To install it you have to use the following command where -g defined the global install (default is local):
npm install -g grunt-cli
First of all, i think you have a typo in your question, you have mixed commit and push commands:
git add .
git commit -m 'commit message' // message is optional
git push origin master
First message appears because you don't have an installed Grunt. Install it in your working directory:
npm install grunt --save-dev
Starting with Grunt v0.4, you should never install Grunt itself
globally. For more information about why, please read this. Source: grunt-cli docs.
If it is alredy listed in the devDependencies, just run:
npm install
The second one is caused by line-endings. It is a good practice to include .gitattributes file in your repo. File's content should be:
* text=auto
Read about this file: docs. Or there is another method. It is described in this question.