FEATURE REQUEST: Dry-run flag

[eitah]

Dear Cogito maintainers, Any chance you'd add a dry run configuration to your pipeline? The idea there is if a pipeline fails rather than alerting as it would do in the staging env, the pipeline step might no-op and alert the user that no request had gone out. We'd love such a feature for our staging concourse environment. I'd PR if you're open to it, or accept suggested implementations if there's something I'm not seeing in your readme. Thanks! Eli

[marco-m-pix4d]

Hello, it is not clear what you are asking. Could you please clarify and make a complete example?

[eitah]

Sure! Our staging environment is a complete mirror of production, meaning the pipelines there make extensive use of your pr resource. With 2 or 3 jobs per pipeline that manage PRs and 4 times per job that cogito is called (once prior to performing an activity, once on failure, once on success, and once on error) the act of disabling cogito notifications in the staging environment prior to working on a new feature could involve as many as 10 blocks of yml to disable or delete in order to not see notifications be pushed back to the PR branches in question.

THe feature I was thinking of is way to tell the resource where cogito is configured to suppress notifications, meaning we could leave the job yml untouched and enable "Dry run" or similar on the resource to suppress notifications in lower environments.

Make sense now or do you need me to explain in a different way?

[marco-m-pix4d]

You mean that you would have two pipelines, almost identical, one for prod and one for staging. The staging one would, say, set dry-run: true in the source settings of Cogito? Actually that line should be there always, and prod would set dry-run: false. This could be done via a ((var)):

dry-run: ((dry-run))

and then

fly set-pipeline ... -y dry-run=false     <- prod
fly set-pipeline ... -y dry-run=true     <- staging

Is this what you mean? I have to think.

[marco-m-pix4d]

@eitah ping

[eitah]

Thanks for following up on this. Yea, you understood the feature request, a source configuration for the resource such that the status is not actually published anywhere for our staging environment without necessitating a lot of conditionals in the YML.