# Automating sensucli publishing

**URL:** <https://discourse.sensu.io/t/automating-sensucli-publishing/1552>\
**Category:** Sensu Go\
**Created:** [January 3, 2020, 6:14pm UTC](https://discourse.sensu.io/t/automating-sensucli-publishing/1552 "2020-01-03T18:14:06Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![marianoDM](https://avatars.discourse-cdn.com/v4/letter/m/c77e96/32.png) [@marianoDM](https://discourse.sensu.io/u/marianoDM)\
**Post date:** [January 3, 2020, 6:14pm UTC](https://discourse.sensu.io/t/automating-sensucli-publishing/1552/1 "2020-01-03T18:14:06Z")

</div>

Thinking in a strategy to get continuous delivery with sensu alerts. Having a repo with alerts and handlers’ definition, committing into that repo and tag as RELEASE\_XX should update config automatically

1- Obvious solution would be to create a Teamcity task that gets the yaml templates and do sensuctl for each file. this has a couple of problems.

- if you rename an entity or check, you have the old and new definition at the same time. either calculate the difference (complex) or delete all entities before each deploy (slow).

- For non-prod Teamcity can reach the env, but for staging and production, granting access to TC worker has security implications. and setting up jenkins servers on each env sounds like an overkill.

2- Use artifactory to deploy each time a new check bundle is deployed.

- this sounds a little better but each sensu server needs a cron to check for a new artifact, download it and validate. then update the bundle.

Do you have a recommended strategy/idea to streamline config ?  
thanks.

---

<div class="post-metadata">

**Author:** ![calebhailey](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.sensu.io/calebhailey/32/46_2.png) [@calebhailey](https://discourse.sensu.io/u/calebhailey)\
**Post date:** [January 6, 2020, 7:20pm UTC](https://discourse.sensu.io/t/automating-sensucli-publishing/1552/2 "2020-01-06T19:20:29Z")

</div>

Great post! I don’t have any direct recommendations or comments at this time, other than to share that this is a pattern we’ve seen implemented elsewhere (i.e. a lightweight CI pipeline w/o traditional configuration management).

What I did want to share are a few related topics/resources:

- GitHub issue [[sensu/sensu-go#3044] “Allow pruning config on create”](https://github.com/sensu/sensu-go/issues/3044) was opened to track this challenge around renamed resources; please comment there with any input/feedback you have.

- Though not a solution for renamed resources, [`sensuctl delete`](https://docs.sensu.io/sensu-go/latest/sensuctl/reference/#delete-resources) was added in version 5.11, which may be helpful in the interim.

I hope this helps!

#monitoringlove