Enforcing policies from Repository merge request check plugin

[Carlos Muñoz]

I need help on how to successfully create a RepositoryMergeRequestCheck

As part of our merge workflow, we need to ensure some policies about some files. Policies includes among others:

• File naming conventions of individual files
• File naming conventio between multiple files
• Inspection of source code to enforce or disallow usage if some statements or functions

I want to be able to check for thiese policies on a repository merge request check so I’m building a plugin for stash:

I have tried the following approaches:

• Using the RepositoryMergeRequestContext parameter of RepositoryMergeRequest.check(). I can say:

context.getMergeRequest().getPullRequest().getFromRef().getRepository()...

Now i get a Repository instance and I’m not sure how to extract commit info from it.

• Calling git directly. Since this check was originally developed as a git hook script, calling git from the SDK made sense to me. It led me to this situation:

String result = gitScm.getCommandBuilderFactory().builder().lsTree().build(…).call() //Where gitScm gets dependency injected in the plugin’s constructor.

Notice the build parameter? It expects a CommandOutputHandler<T> (in this case T is String??), but that's an interface an I'm not sure how to get a n instance that implements that interface or how to create one.

• REST API. REST API looks the easiest of them, but it still doesn't help with the third requirement of inspecting file’s source code and also, spawning web requests from the merge request check that is itself a web request from stash doesn’t seem to be a good idea from the performance side.

What path should I follow or how can I do it?

[cofarrell · Accepted solution]

Hi Carlos,

You're better off doing this in Java rather than REST as that will be much easier and give the best performance. I would recommend sticking to the SCM-agnostic, and high-level APIs. In particular if you want ls-tree then the ContentService.streamDirectory() might be helpful, as well as other methods for inspecting the file content. The HistoryService might also be of interest. Both of these services require the Repository instance you already have - it's just a data bean object, not something you can call methods on directly.

If you're curious about the low-level command builders, or in any case, you might want to see what we did for the file-size plugin (you basically need to create your own CommandOutputHandler depending on the command you're invoking).

I hope that gives you somewhere to start.

Charles

PS. Please keep in mind that MergeChecks run on _every_ page view of a pull request (and subsequent merge). If you're doing something expensive (ie a few calls to Git), this may impact the performance for users. If that is the case, and you measure/notice it being too slow then think about caching.