Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
-
Location:ISSUE
Description
I propose that a special-snowflake self-merge policy be adopted for https://github.com/lsst/lsstsw/blob/master/etc/repos.yaml on that basis that:
- this file is CI configuration data in a simple format; there is no logic for a reviewer to evaluate
- modifications being merged into this file are in the critical path for many development activities
- a lint script (
DM-3151) is run automatically by travis CI on all pushes & PRs to this repository
Proposed policy:
A developer may merge change(s) to the repos.yaml file in the lsstsw repo without formal code review if a github PR has been opened for the change(s) and travis CI has returned a success status for that PR.
(see attached images of github's CI status flags)
Attachments
Issue Links
- is triggering
-
- Done
Activity
Kian-Tat Lim If you pass the `-u` flag to `rebuild` it will download the current version from master. `lsstswBuild.sh` always passes this flag. See DM-3008
This seems perfectly reasonable. In almost all cases it's a single line that is being changed and the person making the change really would like it to be accepted quickly.
I have no problem with this proposal as such. However, if we're now relying on Travis as part of the infrastructure, can please we have that documented & announced somewhere obvious? Even despite Frossie's mail about Jenkins to dm-devel, I know that several folks who aren't regular HipChat-watchers are confused about what it is, and adding another CI system into the mix will make that worse.
John Swinbank I can set the CI status check mark and send the hipchat notification from jenkins instead of travis, it will look exactly the same except for where you get send if you click on the status link. Since the CI build is triggered automatically on push the user doesn't really need to know details about the infrastructure plumbing in advance. Travis was just easier to setup since there isn't a python env currently on our build slaves but this isn't very difficult to change.
Hey Joshua Hoblitt – I have no problem with the choice of technology. Whatever you think works best and is least overhead for you is fine.
I'm just a little worried about the proliferation of technologies and terminologies. If this case really is as simple as "don't hit merge until you see a green tick", that's fine. If there's any further bleed over of terminology or UI from Travis, though, I'm just asking that it should be really clearly documented somewhere obvious what it is and why.
My concern here is just that not everybody is active on HipChat, and I know from talking to folks offline that there's some confusion about the new technologies (Discourse, Jenkins, Travis, etc). being introduced or talked about and how they relate to each other and to existing systems. Don't get me wrong, the new stuff is great and I love it – but simply being clear about what SQuaRE is supporting and what it does would help.
John Swinbank Point completely taken that we need some decent developer documentation explaining all this stuff. Real Soon Now (tm).
Joshua Hoblitt I have confirmed with John that he did not intend his comment as an objection to the RFC.
Joshua Hoblitt: Please document this in https://confluence.lsstcorp.org/display/LDMDG/Adding+a+new+package+to+the+build
I'm going to say this is IMPLEMENTED despite DM-4318 still being open. That ticket is open because the page where the policy is documented needs to be reworked slightly. Regardless, the developer guide does not document the self merge policy. See https://developer.lsst.io/build-ci/new_package.html
+1 from me. Normally the GitHub PR should be associated with a JIRA issue documenting the repo addition/move/rename/removal.
My understanding is that no manual steps are necessary for the new repos.yaml to be used by Buildbot or Jenkins. I'm not so sure about users of lsstsw who are doing manual rebuilds with their own clone.