I know about specifying a local path to feature files (eg #CucumberOptions(features = "<feature_path>") in Java), but is it possible to read feature files from a remote location, ie from Github?
Motivation: I have several API client libraries in different languages that need to adhere to the same set of core specs. I'm using Cucumber feature files as a language-agnostic base for the specs, then writing step definitions for each library. Seems silly to duplicate the feature files for each project, but so far I haven't been able to find out how to read them from a remote location.
For example, setting #CucumberOptions(features = "https://github.com/<repo_path>/features") produces the following error:
Tests in error:
initializationError(com.<package_name>.feature.RunCukesTest):
Not a file or directory: /<local_path>/https://github.com/<repo_path>/features
Note I used Java as an example but I'd love to hear the answer for any of Java/PHP/Ruby/Javascript.
Quite new to Cucumber so please forgive me if this is an obtuse question.
As far as I know, you can't specify a remote location to read feature files from. I imagine a remote location being something you find through a network and not the file system.
You can speciy the path to the feature files and thus use the same feature files for many cases. But that requires you to always keep the code in locations relative to each other. One way of to do this is to use a a so called mono repo. That is one repository for all your implementations. Mono repos are used by some teams with sucess. The Cucumber team is moving in that direction to make it easier to keep common things in synch. All Gherkin implementations, independant of the implementation language, lives in a mono repo.
Why not use Linux FuseFS for such task? curlftpfs, for example
Related
I want to create CI on Github Action for QA Automation. But there is multiple language are use to install dependecies. Can i use NodeJS and Golang at the same file?
I read the documentation of Github Action, but there is configuration for each language not both. Any reference or idea i can use?
In short, you write a manifest file (in YAML) and tell GitHub Actions build agent(s) to execute the commands you wanted in an automatic way. See, there is nothing there bind to a single programming language.
You see per language samples/tutorials, simply because that's how new users/developers to get started with a CI/CD system, and it is easy to write up the necessary steps if focusing on the ecosystem of a single programming language.
The underlying GitHub Actions build machines (if managed by GitHub), however, have almost everything pre-installed, so of course you can use Node.js and Golang tools in the same manifest and you don't need any specific reference.
Open the image pages and learn what tools are preinstalled if you like.
Try it out by combining multiple manifests into the single one, and you will see how it works out.
I'm writing a library and a project that uses the library. It's common with Stack to put both in the same folder and maintain a multi-package project, but I want to have two separate projects instead. Stack has external dependencies for this, but they are specified by locations and the projects runs on multiple machines, so it's inconvenient to specify paths (unless it's possible to have nested Stack projects, but this kinds defeats the purpose of having separate packages). I also don't want to use git locations, because it feels burdensome to explicitly specify commits (or maybe this is not necessary?), and don't want to pack the repository in an archive and then download it each time I change something.
Ideally, I would like to be able to install the library on a machine and then reference it somehow in stack.yaml by its name, not location. Is it possible to do that? If not, is there a convenient way to maintain two separate but related packages?
I ended up using git submodules as jonrsharpe suggested. Works good so far.
I'm planning to use JXCore for two reasons.
to make an executable file with no dependencies for my Node.js project
to protect my javascript source code
First purpose is worked fine, but I can't ensure second thing.
Is it secure from Reverse Engineering if I use JXCore for my project and make a executable file?
Can someone read my source code(javascript) if he broke my executable file?
Thank you for reading.
JXcore is an open source project, so it cannot guarantee source code protection. The source files are not really kept encrypted inside the exe file (native package) - they are only compressed. The packaging algorithm is visible from the source code so people may look into it. Nevertheless it may not be a straightforward task, so probably not anyone can do it. But still, although I haven't see any extracting tools as of yet, it doesn't mean that they will not arrive at some point.
But you may consider adding an extra difficulty layer and obfuscate your javascript files before creating your exe.
I manage an open source project that we currently distribute as a zipped bundle of files. We provide a bundle for Windows and Mac -- we currently expect Linux users to compile it themselves.
This program comes with a bunch of auxiliary files that the user will need to access. These include example files and example/default scripts (like plugins) that the user will need to be able to easily find (preferably not searching through a maze of /usr/local/foo/examples/scripts).
The user will also have their own files (that they may want to store in random locations), but they will also have their own collection of scripts (that they probably want centralized so they are always available).
I would like to support installation in multi-user environments where the user does not have permissions to mess with the program installation. The program will include an API (shared library and header) and a Python wrapper for that too. It would be nice to make those available automatically.
We build the project with CMake - and currently use CPack to bundle the zip files. CPack has much more capability than we are currently using. This is not a mechanical question of how to build the package/installation files, but a convention question of where to put all the stuff?
We would like to have an Application on MacOS, an installer for Windows, and packages for Linux. Mac Apps package icons, fonts, images, etc. nicely, but they don't seem to support user-visible files very well.
I would love for there to be a cross-platform standard way of handling this situation, but I have trouble finding decent examples on individual platforms.
Is there anything better for us to do than just a zip of files?
Providing archive of those extra files is probably one of the best solutions. You may encourage users to download them on first start of program - let users decide where they want them themselves.
first things first , i have seen nwsnapshot. and its not helping.
i am building an inventory management system as a desktop app using node-webkit . the project being built is using compoundjs (mvc javascript library). which have a definite folder structure (you know mvc) and multiple javascript files inside them.
the problem is nwsnapshot allows the app to have only a single snapshot file but the logic of application is spread over all the folders in different javascript files.
so how do i secure my source code before shipping it to client? Or any other work-around Or smarter way (yes, i know about obfuscating).
You can use nodewebkit command called nwsnapshot to compile the javascript code into binary which will be loaded into the app without specifying any js file
nwsnapshot --extra-code application.js application.bin
in your package.json add this:
snapshot: 'application.bin'
It really depends on what you mean by "secure".
You can obfuscate your javascript code fairly well (as well as potentially improve performance) by using the Google Closure Compiler.
I'm not aware of any off-the-shelf solutions to encrypt/decrypt your javascript, and honestly I would question the need for that.
Some people think they need to make it impossible to view their source code, because they're used to dealing with compiled languages where you only ship binaries to users. The fact is, reverse-engineering that binary code was never as difficult as some people think it is, so if there's any financial incentive, there is practically no difference between shipping source code and the traditional shipping of binaries.
Some languages have offered genuine encryption of deployed assets, such as Microsoft's SLPS. It seems to me that the market for this was so small that Microsoft gave it to a partner (just my view). The truth is that most customers are not interested in taking your source code; they're far more interested in your ability to service and support that code in an efficient manner, while they get on with their job.
You may consider to merge the JS files into one in the build process and compile it.