Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-3430

support branch name with / when fetching remote URL with github token

XMLWordPrintable

    • 3
    • False
    • None
    • False
    • Hide
      We now allow users to specify a remote GitHub URL to be fetched using a token, even if the branch name contains a slash. The user can URL encode the slash within the branch name to ensure a proper parsing by paac.

      an example URL with a branch name containing a slash url encoded:

      https://github.com/organization/repository/blob/feature%2Fmainbranch/path/file

      the branch name is called feature/mainbranch and the filename to fetch is /path/file
      Show
      We now allow users to specify a remote GitHub URL to be fetched using a token, even if the branch name contains a slash. The user can URL encode the slash within the branch name to ensure a proper parsing by paac. an example URL with a branch name containing a slash url encoded: https://github.com/organization/repository/blob/feature%2Fmainbranch/path/file the branch name is called feature/mainbranch and the filename to fetch is /path/file

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

      Goals

      Branch names may have a slash and when fetching a URL with github token it will fail since it would not know that this branch name contain a slash and is not part of the filename

      Requirements

      Requirements Notes IS MVP
           
        • (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

              cboudjna@redhat.com Chmouel Boudjnah
              cboudjna@redhat.com Chmouel Boudjnah
              Savita . Savita .
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Estimated:
                  Original Estimate - 1 day
                  1d
                  Remaining:
                  Remaining Estimate - 1 day
                  1d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified