Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-31784

Allow stack-os-matrix to run on forks, not just branches

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: jenkins, lsst_build, lsstsw
    • Labels:
      None
    • Team:
      Architecture

      Description

      One of the problems preventing "normal" handling of community PRs to the Science Pipelines code base is that lsst_build and therefore Jenkins cannot clone from forks. As a result it is difficult or impossible to run CI on a community-contributed PR without creating a corresponding branch in the unforked repo.

      There is some residual code that handles repository patterns that could be used to override the repos.yaml repository URLs, but unfortunately it is considered after repos.yaml.

      Another alternative would be to copy the repos.yaml in the lsstsw directory, append the fork(s), and use that. Later entries should override earlier ones. This appears to be feasible to do within lsstsw/rebuild.

        Attachments

          Activity

          Hide
          tjenness Tim Jenness added a comment -

          Is another option to have lsst_build do the git remote/git fetch/git checkout thing itself if it recognizes a remote syntax for the ticket branch?

          Show
          tjenness Tim Jenness added a comment - Is another option to have lsst_build do the git remote/git fetch/git checkout thing itself if it recognizes a remote syntax for the ticket branch?
          Hide
          ktl Kian-Tat Lim added a comment -

          Possibly, although I'm a little happier with clones that are removed on the next "normal" run than persistent fetches that stay in the cloned state forever.

          Another concern I have is the potential for changes to the PR between staff review and the Jenkins run. That means that the git ref should be an approved hash, not a branch or PR ref.

          Show
          ktl Kian-Tat Lim added a comment - Possibly, although I'm a little happier with clones that are removed on the next "normal" run than persistent fetches that stay in the cloned state forever. Another concern I have is the potential for changes to the PR between staff review and the Jenkins run. That means that the git ref should be an approved hash, not a branch or PR ref.

            People

            Assignee:
            ktl Kian-Tat Lim
            Reporter:
            ktl Kian-Tat Lim
            Watchers:
            Kian-Tat Lim, Lee Kelvin, Tim Jenness
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:

                Jenkins

                No builds found.