[semver:minor] Add mod-private command

[jlourenc]

I am proposing the addition of the mod-private command that set up both git and go appropriately to download private modules.

The command sets for the provided module path:

• the basic auth to use for git operations using https protocol (the command can be further enhanced to support ssh)
• GOPRIVATE go environment variable to bypass GOPROXY and GOSUMDB

It is safe to invoke the command multiple times consecutively for different module paths.

[EricRibeiro]

Hi, @jlourenc 👋

Thanks for opening this PR.

The functionality and implementation of what you are proposing here make sense and would add value to the orb. Instead of creating a new one, I would only suggest merging the mod-private to the existing mod-download command.

From a use-case perspective, they would fit nicely together, and it's one less command to maintain.

[jlourenc]

Hi @EricRibeiro 👋🏼

Thank you for the review.

I think merging commands would work if the aim is to only support a single basic-auth-secret, which I think would solve most of the use cases I have come across. For instance, I would you go about solving the following scenario:

steps:
  - checkout:
  - go/mod-private:
       basic-auth-id: bitbucket-id
       basic-auth-secret: $BITBUCKET_PRIVATE_TOKEN
       path: bitbucket.org/private
  - go/mod-private:
       basic-auth-secret: $GITHUB_PRIVATE_TOKEN
       path: github.com/private
  - go/mod-download-cached

However, I can see the benefit to integrate a mod-private within mod-download for the case of a single private path to configure.

description: "Run 'go mod download'."
parameters:
  basic-auth-id:
    default: oauth2
    description: The basic authentication identifier.
    type: string
  basic-auth-secret:
    default: BASIC_AUTH_SECRET
    description: The environment variable storing the basic authentication secret.
    type: env_var_name
  path:
    default: ""
    description: The private module path.
    type: string
  protocol:
    default: https
    description: The protocol to use to perform Git operations.
    enum:
      - https
    type: enum
steps:
  - when:
      condition:
        not:
          - equal: [ << parameters.path >>, "" ]
      steps:
        - mod-private:
            basic-auth-id: << parameters.basic-auth-id >>
            basic-auth-secret: << parameters.basic-auth-secret >>
            path: << parameters.path >>
            protocol: << parameters.protocol >>
  - run:
      name: "go mod download"
      command: "go mod download"

What are your thoughts?

[EricRibeiro]

I lean towards leaving the authentication flow outside the orb and including the GOPRIVATE configuration step in the mod-download command. To support multiple private repos, the path parameters can become paths and accept a comma-separated list of paths.

And then we would have:

steps:
  - checkout:
  - run: 
        name: Configurate GitHub private repo.
        command: git config --global url."https://${username}:${access_token}@github.com".insteadOf "https://github.com"
  - run:
        name: Configurate BitBucket private repo.
        command: git config --global url."https://${bitbucket_user_id}:${bitbucket_access_token}@privatebitbucket.com".insteadOf "https://privateaccount.com"  
  - go/mod-download:
       paths: "github.com/private,bitbucket.org/private"

For cache support, the paths parameters should also be included in mod-download-cached and relayed to mod-download.

[EricRibeiro]

Although I can see its convenience, authentication with VCS should not be a responsibility of a Go orb. It's a good use-case for a git orb, though.

[jlourenc]

Although I can see its convenience, authentication with VCS should not be a responsibility of a Go orb.

I tend to partially agree/disagree on that statement. I guess it depends where you draw the line: whether you consider "Go" as the commands offer by the go binary itself or Go as an ecosystem including its dependencies (e.g. git, and how to authenticate with git).

I see limited benefit in adding GOPRIVATE handling in go/mod-download given it is a straightforward one line. I see much more benefit in combining GOPRIVATE handling with VCS auth given a specified module path prefix:

• ensure paths are aligned: a single parameter used in two different steps
• advocate for good build configuration for private repos: especially to avoid hitting the default golang proxy or checksum database servers for private repo projects that may have sensitive names

All that being said, I also understand you may not want to include the logic in this orb. Thanks anyway!