Update Config on Every Run

[keithconvictional]

Part 1

Updated the action.yml to represent the correct inputs.

- uses: actions-hub/gcloud@master
  env:
    PROJECT_ID: test
    APPLICATION_CREDENTIALS: ${{ secrets.GOOGLE_APPLICATION_CREDENTIALS }}
  with:
    args: info

The with is looking for inputs args. PROJECT_ID and APPLICATION_CREDENTIALS are environment variables. This will eliminate this warning:

##[warning]Unexpected input 'args', valid inputs are ['PROJECT_ID', 'APPLICATION_CREDENTIALS']

Part 2

Updated the arguments to not check for "$HOME/.config/gcloud" anymore. We were running into an issue where if we want to run two deployments on two different projects using one workflow, project 2 would use project 1's configuration files since .config/gcloud already existed. It didn't matter we were passing in a new PROJECT_ID.

This can be reproduced with:

name: Demo
on:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    # Insert general steps that dont need to be run twice.
    - name: Deploy Project 1
      uses: actions-hub/gcloud@master
      env:
        PROJECT_ID: <ProjectID1>
        APPLICATION_CREDENTIALS: ${{secrets.GCLOUD }}
      with:
        args: "app deploy ProjectID1.yaml"
    - name: Deploy Project 2
      uses: actions-hub/gcloud@master
      env:
        PROJECT_ID: <ProjectID2>
        APPLICATION_CREDENTIALS: ${{secrets.GCLOUD }}
      with:
        args: "app deploy ProjectID2.yaml"

During the project 2 step, it would use ProjectID2.yaml but PROJECT_ID was still <ProjectID1>.

[exelban]

@keithconvictional

Hi and thanks for PR.

I agree with part # 1. (also maybe there is a sense to move from env to args. But it's a broken change and must be saved back-compatibility)

In part # 2. You changed the behavior of action. You deleted the part of code that is responsible to save and restore a credentials for the next steps. But also I understand your problem. It will be better to check if saved credentials exist, but PROJECT_ID is different. And if yes, then update a project id.

[keithconvictional]

Why ask for project id every time if it won't be used? Shouldn't you leave the environment the same as found for future steps? Developers would set the credentials on their own to complete whatever future task, they wouldn't use this action to do so.

[keithconvictional]

@exelban made the changes so backwards compatible and uses inputs instead.

with:
  args: "foobar"
  project_id: "foobar"
  application_credentials: "foobar"

[exelban]

@keithconvictional thanks.

In entrypoint.sh You remove the check if cli is already authorized. In this case, cli will be trying to authorize in every step. And it will be impossible because user can provide credentials only in the first step.

Also will be better to initialize all parameters at the beginning. And set depends on which type user use (env/args). And after that make a check if not empty. It will make a much clean and readable code.

Could You remove comments from action.yml? They're not giving any information. Also in entrypoint.sh there is too many comments.

[exelban]

@keithconvictional I add an option to change the project_id in a multistep pipeline. And update the action.yaml as you propose.