Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Stack Documentation and UX
-
Labels:
-
Epic Link:
-
Team:Architecture
Description
https://developer.lsst.io/stack/adding-a-new-package.html describes how to add Travis CI checks to a repo. I think it can be improved two ways:
- The activation should be done through the Travis CI UI (which they recommend) instead of the GitHub repo's service's settings (which are deprecated).
- Branch protections should be activated only after a repo has successfully been built with Travis. Although this isn't critical, it streamlines the instructions by eliminating some back-and-forth between pages.
A third point is that these instructions should probably be factored into a new how-to topic so that it can service both those setting up new packages and maintaining existing packages.
Attachments
Issue Links
- mentioned in
-
Page Loading...
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link |
|
| Risk Score | 0 |
| Description |
https://developer.lsst.io/stack/adding-a-new-package.html describes how to add Travis CI checks to a repo. I think it can be improved two ways:
# The activation should be done through the Travis CI UI (which they recommend) instead of the GitHub repo's service's settings (which are deprecated). # Branch protections should be activated only after a repo has successfully been built with Travis. Although this isn't critical, it streamlines the instructions by eliminating some back-and-forth between pages. A third point is that these instructions should probably be factored into a new how-to topic so that it can service both those setting up new packages and maintaining existing packages. |
https://developer.lsst.io/stack/adding-a-new-package.html describes how to add Travis CI checks to a repo. I think it can be improved two ways:
# The activation should be done through the Travis CI UI (which they recommend) instead of the GitHub repo's service's settings (which are deprecated). # Branch protections should be activated only after a repo has successfully been built with Travis. Although this isn't critical, it streamlines the instructions by eliminating some back-and-forth between pages. A third point is that these instructions should probably be factored into a new how-to topic so that it can service both those setting up new packages and maintaining existing packages. |
| Remote Link | This issue links to "Page (Confluence)" [ 33382 ] |
| Team | SQuaRE [ 10302 ] | Architecture [ 10304 ] |
| Assignee | Jonathan Sick [ jsick ] |
| Watchers | Jonathan Sick, Tim Jenness [ Jonathan Sick, Tim Jenness ] | Jonathan Sick, Kian-Tat Lim, Tim Jenness [ Jonathan Sick, Kian-Tat Lim, Tim Jenness ] |
Reassigning this to Architecture, although obviously we now use GitHub Actions rather than Travis.
I believe the GitHub branch protection and Actions instructions in the adding-package page are reasonable, and they have fully replaced the Travis instructions.
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
| Resolution | Done [ 10000 ] | |
| Status | In Progress [ 3 ] | Done [ 10002 ] |
I think the preference is for developers to not have to deal with any of this at all. That may best be done as a separate page that describes standardized GitHub repository configurations, but no requirement that developers have to worry about it.