#codefresh (2020-04)

Actually cf_export itself works, but echoing to ${{CF_VOLUME_PATH}}/env_vars_to_export doesn’t.

But we can’t have the values output, which for some reason cf_export does

The documentation around custom plugins is horrendous FYI. It needs a complete rewrite.

@Vidhya Vijayakumar heads up re: documentation for custom plugins

Do you know how to solve this though? I have 3 steps in our plugin. I need the value from the first step for the second and third.

I do not see a way to do this without cf_export at the moment.

Haven’t done any custom plugins either. I really wanted to for one of our latest engagements. TBH, took a look at the docs and realized it was a bigger project than anticipated, so we punted on it.

Can you try adding --global to your cf_export command?

@Vidhya Vijayakumar Can work with documentation team on new documentation. Vidhya, Dan and Oriel are discussing a webinar on custom step development. Maybe Kostis or Anna can lead a rewrite of custom step documentation.

@Harrison Heck It would be helpful for us to have more feedback on each item you find horrendous within the document, so we can take actions on specific items. For example, is this just formatting and readability or lack of examples?

I think it would be easier to have a call about it. In generally, most of CFs documentation needs a refactoring.

@dustinvb What does --global do? We already have cf_export working. What I don’t want is the output it gives.

But doing the echo workaround doesn’t work

cf_export should not ever echo out the value. I have no idea why that was done.

ya, we were bit by this as well.

If you want that, cf_export --show would make more sense. But the default should mimic export, which is safe.

we exported secrets in clear text in the build logs

Yeah, unfortunately CF feels very rushed and not always thought through.

The global flag is used to return the output from the step to the pipeline level.

I really don’t understand what that means.

As I said, cf_export works. But it outputs the value, we don’t want that. So we’re trying to do the echo workaround. This is not sending the value to the next step in the plugin

Here is an example using echo to vars. https://github.com/codefresh-io/steps/blob/master/incubating/vault/script.sh#L49

This sounds like an issue for support to discover why the method to export vars is not working.

Can you please open a ticket? https://support.codefresh.io

I’ll try with /meta being hardcoded first

Ok, that gets me further, it’s actually in the right place now. It seems like CF_ variables aren’t available in plugins, which really makes no sense.

One issue I’ve found unrelated to this is that it seems yq -r is needed, not yq -y. Otherwise we had ... output after the github token. https://codefresh.io/docs/docs/codefresh-yaml/steps/git-clone/#reuse-a-git-token-from-codefresh-integrations

I got it working, but it’s definitely uglier than I would have hoped. The custom plugin stuff could definitely use some work on top of the documentation itself.

I’m happy to have a call to discuss it all.

The problem we have is that we need a currency of 1 for pushes to master, but for PRs, we want it to be unlimited

So we separated our push pipeline from our pull-request pipeline, though it’s the same pipeline code

The problem with this is that when you merge master to our production branch, both pipelines trigger, because there is no way to have it only triggered once

We solved this in a slightly ugly way, but it works.

Personal preference has been to keep pipelines separated by trigger types so the scope of the pipeline definitions is reduced

So we generally have a release pipeline triggered in releases. That’s all it does.

A build pipeline on merge to master.

A destroy pipeline triggers on Pr closed or merged

Etc

@Erik Osterman (Cloud Posse) thats what i currently have. we struggle w/ adding triggers to each pipeline for every new project we have.

ideally, new project = 1 new trigger

in other news, this page which i have visited many many times actually has the bit i was looking for that ive always overlooked i guess: https://codefresh.io/docs/docs/codefresh-yaml/variables/#github-release-variables

We are working on gitops of Codefresh pipelines

But it’s been a real pain to implement

We introduced a new file call app.yaml

Then a Codefresh job that runs every 10 minutes and scans for repostories with that file and configured the triggers for the type of pipelines it wants

does your team struggle w/ trigger management? thats what im struggling with with your current approach

We call these build packs

So with the app.yaml they are setup automatically

But otherwise yes, that is a real PIA

for every new project (builds + feature branch, pr into develop, merge into master, github release)

Especially when having used GitHub actions and it is so easy

thats for simple projects

exactly! i was looking at gh actions last night. I was tempted to actually use the gh actions triggers to trigger specific codefresh pipelines

Codefresh needs to have the ease of use of GitHub actions for pipeline configuration

Way too much clickops with Codefresh

yeah im trying to remove as much clickops as possible which is the exact reason i’m asking this question

So there is an example of using GitHub actions with Codefresh

i unfortunately became numb to it during implementation, but devs voiced their concerns w/ spinning up new projects

I think it might improve the developer experience

Basically remove all triggers from pipelines in Codefresh

Use GitHub actions to trigger all things in Codefresh

yep

thats exactly wat i was thinking of doing

then the gh repo has a single codefresh secret (api token)

and can use as repo template w/ base gh actions yaml config

Also @Zachary Loeber informed me now that GitHub has an api for secrets

yeah i found that out yday when i was looking at gh actions. thats what i mean by codefresh secret

single codefresh secret.

gh action yaml would look somrhing like:

on:
  # Trigger the workflow on push or pull request,
  # but only for the master branch
  push:
    branches:
      - master
  # trigger codefresh build  and test pipeline
  pull_request:
    branches:
      - master
  # trigger merge to master pipeline
  release:
    types: # This configuration does not affect the page_build event above
      - created
   # trigger deploy to prod pipeline 

Ya

i might just do that.

I think it’s definitely worth a try

Zero trigger management then

Just manage one secret per repo

yep that would be ideal

ima give that a shot

@Igor Rodionov

@btai, @Erik Osterman (Cloud Posse) Have you seen this? https://github.com/marketplace/actions/codefresh-pipeline-runner

@Kostis (Codefresh) yep, i forked it. it was a good start but def not quite usable for most pipelines that use the CF_* provided system variables

I’m also planning on allowing arbitrary variables to be passed in probably by using a prefix or something like CFVAR_{ENV_VAR_NAME} Let me know if you guys have better ideas

?

It sucks that this isn’t available at all

@Harrison Heck http://json-schema.org/specification.html

It should be number, string, object, boolean

That’s json schema, that is not the schema of codefresh

There’s a difference.

We need a published version of CF’s JSON Schema