Capability to set a custom server id

[EricDales]

Is your feature request related to a problem? Please describe.

Hello,

• I want to add the .jfrog/projects/maven.yaml to my git repo so the configuration is automatically shared with my team.
• To make it usable in a GitHub Actions workflow, server id in .jfrog/projects/maven.yaml must be the same as the one in ~/.jfrog/jfrog-cli.conf.v6
• setup-jfrog-cli forces the server id to be setup-jfrog-cli-server which is not meaningful to me

Describe the solution you'd like to see

I would like to be able to specify the server id as a setup-jfrog-cli parameter:

        uses: jfrog/setup-jfrog-cli@v4
        env:
          JF_URL: https://${{ vars.JF_DNS }}/
          JF_USER: ${{ vars.JF_USER }}
          JF_ACCESS_TOKEN: ${{ secrets.JF_ACCESS_TOKEN }}
          JF_SERVER_ID: ${{ vars.JF_SERVER_ID}}

Describe alternatives you've considered

• Adding a jf add command in my workflow: it defeats the benefit of setup-jfrog-cli to have a single configuration step

Additional context

Already commented in #86

[tomjfrog]

+1 on this

[prasannanjfrog]

Also adding another issue that can be handled as part of setting up new server ID:

In the post steps for "setup-jfrog-cli," all server configs is wiped. JF config rm is run without a server ID. This hurt the customer as they are using a workflow that contains two composite actions. The first, maven-build-scan, does the ‘jf audit’, ‘jf mvn’, ‘jf scan’ of the Maven project then publishes the Artifactory build. The second, docker-build-push, optionally uses the jf cli to run jf docker push and to publish the build again. Issue: After the workflow has completed, post steps occur. FIRST, the docker-build-push post step occurs which contains a setup-jfrog-cli cleanup call. That call does a ‘jf rt ping’ which is successful. From customer: "Note, it is only successful because we set up the server, not in the docker-build-push action, but the maven-build-scan action. Then it looks to post job summary. This instance of the setup-jfrog-cli has nothing to summarize as it wasn’t used for anything. IMPORTANTLY, it then calls a ‘jf c rm –quiet’." This unfortunately removes the server configuration that was set up in the maven-build-scan action. Next the maven-build-scan post step runs, jf rt ping fails as the server has been cleared, and the customer is unable to see the workflow summary.