Support CRON trigger type for pipeline

[dustinvanbuskirk]

Pipeline does not support CRON triggers.

We need to add this additional trigger type to support pipelines using CRON triggers.

[templarfelix]

have date for solve this issue?

[DanielVVoros]

What is the estimated delivery of this issue?

[sandrogattuso]

@dustinvanbuskirk is there any documentation on how this works from an API perspective? I had a look around the CRON triggers configuration and this is something that is not directly attached to the pipeline.
From what I've understood looking at the API calls made by the browser when editing the configuration, seems you have at least another 2 API endpoints involved in the generation of the CRON trigger.

Adding the feature in the resource_pipeline would go against the recommended practices https://www.terraform.io/docs/extend/hashicorp-provider-design-principles.html#resources-should-represent-a-single-api-object

I can help on the implementation of this but I would like to know if you had any thought around how this would look like from a resource perspective in terraform.

[kpurdon]

@sandrogattuso any update here? I'm happy to help.

From an API perspective this is:

# create an event (returns the "event" which is a string id used in the next call)
curl  \
    -X POST \
    -H "Authorization: ${API_KEY}" \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d '{"type":"cron","kind":"codefresh","secret":"!generate","values":{"expression":"0 0 1 1 1/1 ?","message":"some message"}}' \
    "https://g.codefresh.io/api/hermes/events?public=false"

# use the result as EVENT and attach it as a trigger to the pipeline
curl -X POST \
     -H "Authorization: ${API_KEY}" \
     -H 'Content-Type: application/json; charset=utf-8' \
     "https://g.codefresh.io/api/hermes/triggers/${EVENT}/${PIPELINE}"

from a Terraform resource perspective this would ideally be:

resource pipeline {
    trigger {
        // config here
    }

But as designed the trigger block is pretty overloaded. I could see either a separate trigger resource which takes a pipeline id, or a seperate trigger_cron block in the pipeline resource.

[kpurdon]

@yaroslav-codefresh @denis-codefresh @pasha-codefresh (sorry; still unclear who maintainers are)

How can we move this forward; the main questions seem to be around design of the pipeline:trigger resource with the addition of CRON type triggers.

I (and possibly @sandrogattuso) have offered time to help implement; but I wouldn't want to dig in without design guidance from maintainers.

[denis-codefresh]

From my perspective it's better to embed trigger_cron resource in the pipeline (make a new block).
Event if API looks different for cron and git triggers it's better to keep them at same place in your "infrastructure code".
@ziv-codefresh WDYT?

[kpurdon]

@denis-codefresh any update here? Can you make the call on a preferred design? If I were to put in the work for a trigger_cron would that be accepted?

[Laurent-OC]

@denis-codefresh any update here?

[expnch]

@denis-codefresh We are still waiting on an update.

[denis-codefresh]

@kpurdon Let's create a new trigger type block in addition to a regular trigger called cron_trigger.

[korenyoni]

Hi all. Sorry for the huge delay. We didn't really have a maintainer assigned to this repo (until now).

Basically, @denis-codefresh and I agreed that the git_trigger block should be deprecated, and standalone resources for each of our triggers should be supported:

• codefresh_pipeline_git_trigger
• codefresh_pipeline_cron_trigger
• codefresh_pipeline_helm_trigger
• codefresh_pipeline_registry_trigger

By the way, git triggers and the other 3 types of triggers use completely different APIs. Just something to note. The last 3 triggers in the list are based on something called hermes and thus use the hermes API in Codefresh.

There is some WIP stuff here in my fork https://github.com/korenyoni/terraform-provider-codefresh. We are also overhauling documentation, release automation, and probably a couple other small things we can fit into a minor release (0.1.0). We are expecting some turnaround on this in the next two weeks. My goal is to get this repo into better shape...

[korenyoni]

We have a PR open for this now. What I said about the other 3 types of standalone triggers is actually going to be moved out to 0.2.0, even though it would have been ideal to release all 4 as part of 0.1.0 and deprecate the inline trigger.