search

NSLS-II-BMM / profile_collection

BlueSky configuration for NSLS-II beamline 6BM, BMM
https://wiki-nsls2.bnl.gov/beamline6BM/index.php/Main_Page
Other
3 stars 7 forks source link

Configure Azure Pipelines CI #1

Closed mrakitin closed 5 years ago

mrakitin commented 5 years ago

This PR adds config files for the Azure Pipelines integration enabled via a direct push to master via c312302e317c2ade92b8e32835bb39cb025111d3.

xref https://github.com/NSLS-II/profile-collection-ci/issues/2

bruceravel commented 5 years ago

Maksim, Do you want to ... oh, I don't know ... tell me what this is for? What is does?

mrakitin commented 5 years ago

Sorry for the confusion, @bruceravel, we should have announced this activity earlier.

We are working on testing the beamline collection profiles against the same collection conda environments we deploy. This will allow us to produce conda environments, well-tested in combination with the IPython startup files, before the conda environments are actually deployed to the experimental floor. Typical problems such as missing (or conflicting) package dependencies, uncommitted data/config/python files and non-compliant PV names can be tracked down much easier and earlier with this approach.

Azure Pipelines is a ~new tool from Microsoft aiming to provide a seamless platform for building and testing software projects under Linux, OSX, Windows in the cloud. See more details here. We picked this tool as it can be a replacement of already known CI systems (TravisCI, CircleCI, Appveyor, ...) with a convenient configuration.

To enable it, I had to push the azure-pipelines.yml file to the root of the repo (master branch), which then was picked up by the enabled GitHub App from https://github.com/marketplace/azure-pipelines. That file instructs Azure to pick the job steps from https://github.com/NSLS-II/profile-collection-ci/blob/master/azure-linux.yml. This way the testing instructions can be managed centrally for all NSLS-II beamlines. You may notice, that we use caproto-spoof-beamline IOC there as a replacement of real IOCs -- this is to allow the startup files to load successfully.

We have a combination of the following parameters:

The status of the jobs can be found at https://dev.azure.com/nsls2/profile_collections/_build/results?buildId=101 for the latest build. The failed builds correspond to the nsls2forge channel due to a missing beamline-specific metapackage in that channel (will be fixed soon).

You can interpret the current test results as follows: your profile_collection will load fine using bsui with conda envs with packages from the lightsource2-tag conda channel with Python 3.6/3.7 and pyepics/caproto.

Does it answer your question?

bruceravel commented 5 years ago

That's all great and I have no problem with it. My problem was with an unexplained PR that could not be readily understood from context. You have to understand that the only sensible response to that kind of PR is to reject it. With some context, however, I am all aboard!

mrakitin commented 5 years ago

@bruceravel, I feel it would have been clearer if I put my explanation into the description and labeled it as "internal DAMA process". It was my bad I didn't make this PR a "draft" one, as I still wanted to work on the missing packages, and to make sure all tests pass before merging, but I can do it with the code from master or will submit a separate PR. Thanks for merging!