Change Request (ServiceNow) Resource

We are looking to integrate ServiceNow change requests into concourse.

The thought was to create a resource for it but wanted a little feedback as to best practices and how to implement this.

The use case is this…

  1. in a job we want to create a NEW change request
  2. the next job in the pipeline wants to get that CR (hopefully from a resource) and update it
  3. more jobs will also want to use the CR to update it
  4. in a final job we will close the CR.

The concerns we have is this doesn’t really fit in a resource. There will be no “check”, the “in” is definitely used as is the “out” but check doesn’t really make sense since it would be difficult to write in this sort of scenario and anything we did would seem a little hacky.

Has anybody else implemented a change request flow as a resource (using service now or some other change request system)? How did you do it? How does it work?

We also thought this fits in our env with a “pool” as we use pools to lock the env and so wanted to know if this could integrate with the pool “metadata”.

We usually “lock” the env in our first step (which would then create the CR) at this point we would want to save the CF number as part of the metadata.

Then all the subsequent jobs would read the lock metadata and use that CR info.

Our final step which releases the lock would also clear out the metadata.

Has anybody used this flow or would recommend a way to implement it this way?

Thanks!

Andrew Edgar

Disclaimer: I’ve never used ServiceNow

What makes check difficult to implement?

In general, if your workflow doesn’t fit specifically into a ‘versioned artifacts’ workflow I’d be hesitant to push it into the resource interface. To be a versioned artifact, check should be able to find the same versions that out creates (including any versions that were already there), in chronological order.

If it’s not a good fit, it might get a little better in the future as we’re planning to expand resources to support other use cases beyond just versioning artifacts. There’s an update on that in the latest roadmap post.

Do you think you could summarize the difference between this workflow and versioned artifacts? Is it more like a set of open change requests, and you need to be able to create one and propagate it through a pipeline? (Could check be implemented to just return the full set, i.e. a ‘spatial’ resource as talked about in my roadmap post?)

Thanks for the feedback. Good to hear and read the roadmap post as yeah I think this does sort of fit in the “spatial” resource.

I was thinking that the check could return a full list (or even a partial dated list).

We do want to have “put” create a new change request. So that does work and then the subsequent jobs would read this new version that was created and flow it through. We would then use a final “put” to close the change which would in theory remove it from the list of things the “check” would return (as we really only want to return “open” CRs).

I need to think on this a little more to see if I can use the check to return the full set. Which in most cases is empty but periodically can be not empty (if we have just created one).

I’m now thinking I might be able to make it work cleanly like this…

Check - returns list of open change requests for a particular env
Put - create or update a CR
Get - get the current CR information.

The check will be kinda interesting as it will change the list it gets as CRs come and go. Is that ok? Will that break how things usually look? Because now going back in history I will not be able to see the version that flowed through some jobs because it is no longer in the resource list?

That should be fine. I think this is of how the GitHub PR resource works. The ‘deleted’ versions will actually stick around.

When we implement v2 resources Concourse will start marking these versions as ‘deleted’ - in fact your use case for closing the change request could be modeled as a delete action in v2 so put isn’t overloaded.

Yeah, the more I hear about this the more it sounds like a spatial resource. :slight_smile:

Out of curiosity, would your workflow intuitively lead to one-pipeline-per-CR? i.e. would you have multiple CR’s “in flight” and want to monitor a pipeline for each one? That’s pretty much how I’ve been reasoning about pull requests and branches - the two primary use cases for spatial resources.

You are absolutely right we would only have things flow through the pipeline one at a time. we would never have 2 in flight at the same time. we drive right now off git commits. so we are flowing a git commit through the pipeline. Part of flowing this through needs to create the CR so we have a traceability of this change through to the env.

Exactly the same sort of flow as testing and merging a PR !

@vito . So I’m in the process of implementing the ServiceNow CR resource.

I am in the “put” doing a Create of a new CR. But then there is the automatic get (which I read can be opted out of which would be great!) . but this get now does NOT have the CR number from the put (as it just got created) . how do I get the automatic GET to have the values created in the PUT?

I figured it out. I was not outputting the version correctly on the PUT. Now it’s working.

@andrew-edgar I’d be interested in this, do you have the code for the resource to share?