release to npm could run any script in package.json. Why limit it?

[ghost]

It seems to me that the 'plugin' in this case, is simply a baseline docker image plus sample syntax for how to run a command within it that is otherwise identical to a Freestyle step. All of the work of installing the script in package.json and telling the plugin which command to run is still an exercise for the user. All that's required is a docker image with npm (or the npm client of your choice) and you can do the same thing in a Freestyle pipeline step without any syntax changes.

Wouldn't it be more useful to just have a plugin for running npm-based steps, which provides a codefresh-approved npm environment (which should probably have npm, yarn, and lerna all installed, plus node), and then instead of specifying the entire npm command in the commands list, allow the user to just specify the name of the scripts that should run plus any parameters. The actual npm client can be specified in package.json. The syntax would be more like this:

npm_step:
title: Running something via npm
image: codefresh/npm-tools
token_var: NPM_TOKEN
commands:
- build --production
- prerelease --production
- release

The plugin would then know how to structure the npm commands, including the addition of the npm token via the var that was specified. Otherwise, i don't see much difference between the 'plugin' and a Freestyle step with identical syntax, other than the type of the step.

In my example, I can set my npmClient to be yarn in package.json. And if I use lerna to update versions and push npm packages, I can set up a 'release' script which calls 'yarn run lerna publish.' Even so, it's about the same number of lines of code whether using the plugin or just running a Freestyle step, so there doesn't seem much value in the re-usable component. A naive npm user may not realize how easy it would be to add commands other than release-to-npm to such a step, for example.

[kostis-codefresh]

It seems to me that the 'plugin' in this case, is simply a baseline docker image plus sample syntax for how to run a command within it that is otherwise identical to a Freestyle step

It is clearly mentioned in the README file that "Codefresh Plugins are Docker images made especially for use in a Codefresh freestyle step"

Wouldn't it be more useful to just have a plugin for running npm-based steps

That is a great idea, but remember that different people have different needs. Some would like a generic plugin that can do anything like you describe and some would like separate plugins that do specific things. In a similar manner that some people like an IDE and some prefer a terminal and many command line tools.

The main concept of the plugins repo is exactly to showcase the power given to the developer by Codefresh CI. Unlike other CI providers where you have to wait from the vendor to provide a specific version of a tool, Codefresh allows you to build your own Docker images that are used for tooling. For people that are expert on Docker this might seem trivial, but for others it might be mind-blowing.

That being said, the whole repo is public and is not restricted to Codefresh employees. So if you have a great idea for a plugin (such as the NPM one that you mentioning) feel free to open a PR with the code. We welcome contributions.

Each plugin also has a readme that shows the YAML syntax that can be used.

Some people like building things from scratch and some like to use lego blocks without too much customization. Codefresh plugins can be both.

[ghost]

OK. I'm not sure I'd call that a plugin or refer to them as custom steps, since they are really just example Freestyle steps. The term plugin causes me to expect that it would eliminate boilerplate or repetitive syntax via code re-use, or allow me to condense multiple steps of other types into a single step, while these are really just handy docker images for use in Freestyle steps, plus sample steps. There are lots of potentially useful containers already available without requiring a custom build. A curated list of useful images that are provided by well known providers who can be expected not to release images with malware or security holes, along with some command recipes for using them would be useful, but I'm not sure calling them plugins and abstracting that from the core documentation about pipeline construction is a useful abstraction.

buildpack-deps is super useful.
node is based on buildpack-deps and gives you the version of node, npm, and yarn that is compatible with the node version specified in the tag (node:10, for example).
stedolan/jq is maintained by the author of jq, and provides that tool.
Most database systems have images that have client tools installed, for interacting with databases.
Amazon linux is available as a docker container, which gives you aws-cli functionality and more.

But I'd just call a library of example steps a Freestyle cookbook, rather than a collection of plugins. That would also help potential users understand how to find more thorough documentation of what is going on in each plugin, and how to extend the example to other functionality.

[ghost]

For example, here's a step which extracts a version number from a package.json file and exports it for use by other steps, perhaps as a tag in a docker repo:

  GetVersion:
    description: Exporting Version from package.json
    title: Export Version
    image: stedolan/jq
    commands:
      - cat ./package.json | jq .version | xargs cf_export VERSION =

But that's all just documentation. There's no custom code there at all, other than the command that executes.

[kostis-codefresh]

But that's all just documentation. There's no custom code there at all, other than the command that executes

I can see where you are coming from, and that is certainly true for the npm plugin (that you are talking about originally in this issue). But have you checked the other plugins? They do have custom code.

The deploy-to-ecs for example has cfecs-update
The deploy-to-dcos has cf-deploy-dcos
The slack plugin has slack-message-sender

So what you are saying is certainly not true for them. The Codefresh Cli plugin is obviously as custom as it gets as well.

Then there are some plugins that don't even require commands at all (e.g. the Jenkins one)

Let me put it another way. Let's say that a user who is expert on Jenkins but knows little about Docker images and how creating one works (maybe he doesn't even care) is evaluating Codefresh. He wants to call a job from Codefresh to Jenkins.

He finds the Jenkins plugin, copies the yaml segment and puts it into the Codefresh UI. He just edits some environment variables. Now he has achieved what he wants without actually caring about Docker at all. Did he find the Jenkins plugin useful? Yes. Does he need to know how it works? No? Does he need to extend it? No, it just works