GitHub and Cloverleaf

[Max Drown (Infor)]

Has anyone out there implemented GitHub with Cloverleaf? I’m looking for some advice on how to best do this.

-- Max Drown (Infor)

Topic

[Austin Adams]

I have not but it does sound interesting.  Also, I think Infor needs a Slack workspace.

[bill bearden]

When I saw Max’s post the other day, I was hopeful someone would have figured out something cool. Our organization has just started the process of implementing some of the Atlassian products: Jira, Confluence, and Bitbucket. My boss asked me to work out how the interface team could use Bitbucket with Cloverleaf. I think Bitbucket is similar to Github in that it is a layer on top of Git that tries to make it a little easier to use.

I had already searched Clovertech and found some interesting topics. In 5782, Stephan Rubin states that (my paraphrase here) Git and Cloverleaf are not compatible because Git is very client oriented and Cloverleaf is server oriented. Stephan suggests having a workstation version of full Cloverleaf on each developers’ PC. But that would require different Cloverleaf licensing. And I don’t know if it would be worth the trouble just to say you are using Git.

I think I also read someone suggest that one could set up individual sites on the server for each developer and test environment. For example, we have currently dev and test sites on our test server. If each developer had had their own dev and their own test, they could work independently of all the users actually testing using the real dev and test. But when the code changes were good enough, they could commit in their own site and push to the “real” dev or test. But this doesn’t address deploying to prod.

In 7884, Paul Glezen mentions some of the issues with automated deployment to prod.

Also in 7884, Benjamin Rubin said he set up a script to do daily Git commits and then push to a central server. So far, that seems like the best suggestion.

[Stephen Davis]

Seemingly several years late to the discussion here but we are running 6.2.2 on RHEL 7.4 and have an on-prem version of gitlab. We are using a script called gitwatch (https://github.com/gitwatch/gitwatch) which uses the git client and inotify-tools to ‘watch’ sever-side folders such as tclprocs, xlate, etc.

When modifications are done to something in these folders via the Cloverleaf IDE, it does a commit ~2 seconds later and pushes to the appropriate repository. This essentially covers versioning a lot better than the versioning built in to Cloverleaf.

I am working on setting up pipelines so that we can trigger deployments from DEV -> TEST -> PROD via git as well.

[Joshua Myers]

Hey Stephen – curious what your approach is to repos and branches.  We are a software company (not a hospital) that uses github extensively, and I’m trying to figure out the best way to adapt it to Cloverleaf’s architecture.  Automated deployment is one the goals (at least for things like procs, xlates, formats, and tables – I don’t think something like NetConfig would work) as well as just versioning.

My 2 ideas right now are either:

1.  Separate repos for our TST and PRD boxes.  This makes promotion tricky as we’d have to figure out how/when to pull from the TST repo, install into PRD, then push back to PRD.

2.  1 repo with master branch for PRD, develop for TST, and maybe feature or bugfix branches.  This would better match a modern day development process, but I’m not sure if this would work for Cloverleaf’s architecture.  

thanks for any input

[Stephen Davis]

Yeah, it does get tricky as this isn’t what you’d call typical software development. My thought was to perhaps set up a CI pipeline in Git so that you had build/test/deploy stages as described on https://docs.gitlab.com/ee/ci/yaml/README.html. I would think that you could set up triggers so that when one modifies something like an Xlate in the DEV environment, it would push to that branch (either manually, or with autocommit from gitwatch as described in my previous post) and be ready in the pipeline.

Once the pipeline is run, it could pull the dev branch to the test environment (build stage) and execute scripts to validate the file using the command-line tools in cloverleaf such as hcixlttest, hciroutetest, etc. (test stage). Then, depending on how things come out, push to production immediately or at a set date time as you would with nightly builds or scheduled updates. You could even apply the changes with the after_script directive in the .gitlab-ci.yml file to do something like hcicmd -p $PROCESS -c ‘$THREAD pstop/pstartt’ to cycle the processes and threads to make the change active.

[Author]

Replies