Add Support for External Status Checks

[adam-moss]

Add support for the configuration of external status checks per https://docs.gitlab.com/ee/api/status_checks.html.

This is an Ultimate tier licensed feature.

I would be willing to implement this with appropriate guidance into project workings 👍

[amimas]

I would be willing to implement this with appropriate guidance into project workings 👍

That'd be great @adam-moss . If you have access to a license, I'd suggest using that following the contributing docs so that you have a local gitlab instance for running acceptance tests (after you've written the tests :)). Otherwise, maybe signup for a gitlab trial. Speaking of tests, I guess you'll need to use add a tool in local dev setup that can be used as an external service that acceptance tests will communicate with.

I recently found the contributing docs/setup needs a small tweak when using a licensed gitlab instance. I'll try and make an update when I can so that the setup steps are clearer.

[amimas]

Do you have any suggestion/proposal of what the config syntax would be like?

[adam-moss]

At the moment, nope. The api is fairly simple https://docs.gitlab.com/ee/api/status_checks.html#create-external-status-check-service

So I'm thinking something like

external_status_checks:
  - name:
    url:
    branches:
      - 

Or similar.

However... it isn't supported in python-gitlab yet (ref python-gitlab/python-gitlab#2632) so might need to look at that first if you're wanting to move to that for the interface?

[adam-moss]

Would be nice for #504 to be merged to start validating it ;)

[amimas]

At the moment, nope. The api is fairly simple https://docs.gitlab.com/ee/api/status_checks.html#create-external-status-check-service

So I'm thinking something like

external_status_checks:
  - name:
    url:
    branches:
      - 

Would the following make sense for the syntax by putting the config under existing project object?

project:
  external_status_checks:
    <name-of-service>:
      url: ...

Under <name-of-service>, I think rest of the parameter should follow Gitlab's API. It should take advantage of GitlabForm's raw parameter passing design/architecture. And I used <name-of-service> to follow branch protection, pipeline schedule, etc instead of having name as a separate config key.

I'm suggesting to put the new config under project just because I'm not sure if the new config needs to be another top level key/object. Unfortunately other "CI related" settings/configs are under project_settings but having this new one under that might be confusing. So, I thought grouping it under project is probably the closest pattern. Currently top level configs in gitlabform don't really represent a gitlab feature. This might also require tweak to "inheritance breaking" if a new top level config is added (i'm not sure).

One other suggestion I might add is to include the support for enforce as well. I guess this could be implemented separately but it's probably easier to do it at the same time as this feature being implemented since one would have access to the gitlab license for testing anyways.

Or similar.

However... it isn't supported in python-gitlab yet (ref python-gitlab/python-gitlab#2632) so might need to look at that first if you're wanting to move to that for the interface?

I don't think using python-gitlab would be a requirement. We need more contributors to help moving existing codes of gitlabform to use python-gitlab. I imaging it might take awhile.

[amimas]

Would be nice for #504 to be merged to start validating it ;)

I've been slowly chipping away at it when I can get some time :). Have been learning lots of new stuff.

Just out of curiosity though, how would that help this feature's implementation?