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

Please support better config for lsstsw, including an option to use git@ URLs

    XMLWordPrintable

    Details

    • Team:
      SQuaRE

      Description

      It would be very helpful to developers if the lsstsw tool supported a means of configuration that was not in a file checked into the git repository. That way we could update lsstsw at will without losing our configuration.

      The two config items I care most about are:

      • Use git@ URLs for developers instead of http::, so developers can easily push changes. The present workaround is to manually edit repos.yaml to change all URLs, but this is clumsy and breaks every time the repos.yaml file needs an update.
      • The number of cores to use for a build.

      One possible solution for the first item is to use a symbol in repos.yaml that gets replaced with the appropriate prefix depending on the config option.

        Attachments

          Activity

          Hide
          jhoblitt Joshua Hoblitt added a comment - - edited

          It is intentional that only the git and https URL schemas are allowed by the linter in repos.yaml. The reason is that there isn't, for any practical purpose, anonymous ssh access and I want to avoid having to deploy ssh private keys onto build slaves. Tim Jenness and I have discussed this a bit in the hallway and I'm not particularly fond of any of the options we've come up with. Ideas thus far are:

          • provide two different repos.yaml versions for CI and developers. I'm convinced that this would promptly lead to synchronization issues.
          • put a template-token into repos.yaml that is interpolated to different values depending on use case. I'm not enthusiastic about human brains having to parse this.
          • match URLS with github.com as the host component and do substitution magic similar to above. This is probably the best of the 3 options but I'm concern about developer confusion.

          The REPOSITORY_PATTERN environment variable is still respected by lsst_build but values from repos.yaml take precedence. To use it either the rebuild script would need to be edited or lsst_build prepare could be executed directly omitting the --repos options.

          Show
          jhoblitt Joshua Hoblitt added a comment - - edited It is intentional that only the git and https URL schemas are allowed by the linter in repos.yaml . The reason is that there isn't, for any practical purpose, anonymous ssh access and I want to avoid having to deploy ssh private keys onto build slaves. Tim Jenness and I have discussed this a bit in the hallway and I'm not particularly fond of any of the options we've come up with. Ideas thus far are: provide two different repos.yaml versions for CI and developers. I'm convinced that this would promptly lead to synchronization issues. put a template-token into repos.yaml that is interpolated to different values depending on use case. I'm not enthusiastic about human brains having to parse this. match URLS with github.com as the host component and do substitution magic similar to above. This is probably the best of the 3 options but I'm concern about developer confusion. The REPOSITORY_PATTERN environment variable is still respected by lsst_build but values from repos.yaml take precedence. To use it either the rebuild script would need to be edited or lsst_build prepare could be executed directly omitting the --repos options.
          Hide
          rowen Russell Owen added a comment -

          In response to Joshua Hoblitt's comment...

          I basically agree. I am reluctant to start from a valid repos.yaml and rewrite URLs under the hood because that seems too magic to me. So I prefer a solution that uses a token. But I realize that can make it harder for a user to find a repo. The following solution might strike the right balance:

          • Provide the template, perhaps named repos_template.yaml
          • Save the actual repositories generated from the template in another file, e.g. repos.yaml, and make sure it starts with a big comment saying that it is auto-generated from repos_template.yaml and thus must not be edited.

          Thus users can see exactly what repos were used, but only one file has to be maintained.

          Show
          rowen Russell Owen added a comment - In response to Joshua Hoblitt 's comment... I basically agree. I am reluctant to start from a valid repos.yaml and rewrite URLs under the hood because that seems too magic to me. So I prefer a solution that uses a token. But I realize that can make it harder for a user to find a repo. The following solution might strike the right balance: Provide the template, perhaps named repos_template.yaml Save the actual repositories generated from the template in another file, e.g. repos.yaml, and make sure it starts with a big comment saying that it is auto-generated from repos_template.yaml and thus must not be edited. Thus users can see exactly what repos were used, but only one file has to be maintained.
          Hide
          frossie Frossie Economou added a comment -

          Is using a credentials cache and sticking to https push not an option?

          https://help.github.com/articles/caching-your-github-password-in-git/#platform-linux

          You can even use your OSX keychain if you have a Mac:

          https://help.github.com/articles/caching-your-github-password-in-git/#platform-mac

          The credential-helper comes with git on OSX if you are using homebrew.

          Show
          frossie Frossie Economou added a comment - Is using a credentials cache and sticking to https push not an option? https://help.github.com/articles/caching-your-github-password-in-git/#platform-linux You can even use your OSX keychain if you have a Mac: https://help.github.com/articles/caching-your-github-password-in-git/#platform-mac The credential-helper comes with git on OSX if you are using homebrew.
          Hide
          tjenness Tim Jenness added a comment -

          I have a vague recollection that https doesn't play well with 2 factor authentication but I may be misremembering.

          Show
          tjenness Tim Jenness added a comment - I have a vague recollection that https doesn't play well with 2 factor authentication but I may be misremembering.
          Hide
          rowen Russell Owen added a comment -

          http URLs work fine and there are ways to reduce the number of cores, so no need to do anything with this ticket

          Show
          rowen Russell Owen added a comment - http URLs work fine and there are ways to reduce the number of cores, so no need to do anything with this ticket

            People

            Assignee:
            frossie Frossie Economou
            Reporter:
            rowen Russell Owen
            Watchers:
            Frossie Economou, Joshua Hoblitt, Mario Juric, Russell Owen, Tim Jenness
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Jenkins

                No builds found.