Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-6100

Support git-ask-pass in gitops

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • GitOps
    • None
    • None
    • Future Sustainability
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None

      < High-Level description of the feature ie: Executive Summary >

      Goals

      My customer usually specifies "git_ask_pass.sh" in core.askpass as config to authenticate to the GitLab repository.

      This git_ask_pass.sh uses a certificate file and a key file to get an access token from GitLab and set a password. (Username is fixed to oauth2)To access GitLab repositories from OpenShift GitOps, we want to do the same thing and set the credentials to access the repositories.

      1. Is it possible to configure/incorporate the above process into OpenShift GitOps?

      2. If yes, is the configuration itself supported?
         (I am aware that the content of the configured script itself is not supported, as it varies from user to user.)
      3. If Yes, are there any specific examples?

      This feature may already be implemented to some extend in upstream, but there is no upstream or product docs for it. Related argo-cd upstream PR/issues:

        • (Optional) Use Cases

      < What are we making, for who, and why/what problem are we solving?>

      Out of scope

      <Defines what is not included in this story>

      Dependencies

      < Link or at least explain any known dependencies. >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

      What does success look like?

      < Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

      QE Contact

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Impact

      < If the feature is ordered with other work, state the impact of this feature on the other work>

      Related Architecture/Technical Documents

      <links>

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              halawren@redhat.com Harriet Lawrence
              cfang@redhat.com Cheng Fang
              None
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                None
                None