Hi @petersamokhin,

I"m not familiar with Google Cloud in general, including Google Cloud Secret Manager, so pardon me if I"m doing dump questions here (for context, I"m a software engineer, not a DevOps guys).

I feel that this feature is too specific for Task. In other words, it"s possible that we"d be maintaining it for a single company to use, which is non-ideal. We try add features that are more generic and serves to a wider range of use cases.

How does Google Cloud Secret Manager really work? It authenticates and then adds variables to the ENV? Do you mind pasting your "boilerplate-ish" version as a example so I can understand better?

I want to understand if we could add any non-GCP-specific feature that would work not only for you, but also for AWS for example, and even different scenarios not necessarily related to cloud authentication.

I feel that this feature is too specific for Task.

I tend to agree. My expectation here is that you would use existing tools to fetch secrets from GCP such as the gcloud CLI and then call these commands from inside Task by using a service account.

If the aim is to fetch secrets during CI, then there are also existing GitHub actions to fetch secrets (and I"m sure other CI providers have similar solutions).

Supporting this inside Task creates an expectation that other providers will also be added in the future and this is a sizeable amount of functionality to maintain (with domain specific knowledge) that is currently outside the scope of a task runner. To my knowledge make does not have any functionality of this kind.

hey there! thanks a lot for the swift and detailed responses.

@andreynering

for context, I"m a software engineer, not a DevOps guys

I"m a software engineer too; even more — a mobile developer 😺

we"d be maintaining it for a single company to use

Introducing this kind of functionality (like in this PR) IMO would make task even more popular.
Given the nature of the project, I don"t see any elegant ways of making task more extendable, e.g. by adding a plugin system, so adding the optional additional features enables the new convenient usecases.

How does Google Cloud Secret Manager really work?

Just like the GitHub Actions secrets, Vault, AWS secrets or whatever else: secure key-value storage.

It authenticates and then adds variables to the ENV?

This exact manager in my PR — yes, it either authenticates OR uses the existing auth, e.g. if you have the local development setup and gcloud auth already done. Especially the manager just allows to retrieve the secret values by keys and assign them to vars/env.

Essentially it adds a more advanced & convenient version of sh dynamic variable and that"s it:

version: "3"

vars:
  # before: some steps skiped (auth, project selection)
  FOO_BAR:
    sh: gcloud secrets versions access latest --secret=my-secret-key
  # after
  FOO_BAR:
    gcp: my-secret-key

And the second feature in the PR, yes, it adds all vars/env from task to the GitHub actions environment.
It is not related to GCP at all.

if we could add any non-GCP-specific feature

Yes, easily, most of the logic is very abstract in the PR. Adding Hashicorp Vault, AWS, and whatever else secrets or cloud providers, is gonna be very easy. A new manager and a few lines of code in the compiler and that"s all.

@pd93
Yes, it"s obviously possible to use gcloud CLI or any existing GitHub Actions, however, it"s not really convenient and really boilerplate-ish to me. I really like writing less code :)

Supporting this inside Task creates an expectation that other providers will also be added in the future

Yes, but it"s an open-source repo, innit? 😸 If anybody is gonna expect any functionality, they are free to do it themselves.
Just like I did (not being a golang/devops/backend/script developer at all).

make does not have any functionality of this kind

Yes, it doesn"t; this logic is absent in make, as well as some other features of task. It"s also less convenient to me, that"s why I"m here.
Given the existing logic with vars (especially the dynamic ones), includes, etc. and the name of the project (task), I really think that this addition would only make task better.

Not insisting on merging this PR anyway: I already prepared a custom version of binaries and even a GitHub Action to set it up. But it"d be great.

Cheers!

For comparison, the boilerplate I meant above:

Before

gha-workflow.yml

name: gha-workflow

jobs:
  job_id:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - id: "auth"
        uses: "google-github-actions/auth@v0"
        with:
          credentials_json: "${{ secrets.gcp_credentials }}"

      - id: "secrets"
        uses: "google-github-actions/get-secretmanager-secrets@v0"
        with:
          secrets: |-
            my-secret:gcp-secret-id

      - run: task something
        env:
          MY_SECRET: "${{ steps.secrets.outputs.my-secret }}"

Taskfile.yml

version: "3"

tasks:
  something:
    cmds: echo {{.MY_SECRET}}

After

gha-workflow.yml

name: gha-workflow

jobs:
  job_id:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - uses: whatever/setup-task@v1

      - run: task something
        env:
          TASK_GCP_CREDENTIALS_JSON: "${{ secrets.gcp_credentials }}"

Taskfile.yml

version: "3"

tasks:
  something:
    vars:
      MY_SECRET:
        gcp: gcp-secret-id
    cmds: echo {{.MY_SECRET}}

With more secrets used it becomes much worse. Also, it"s possible to extract the vars to a separate file and optionally include it based on the env or OS, which would be extremely inconvenient to do with make/envfile/other github actions.

hey there @andreynering @pd93! could you please review the above and give a decision? 🙂
if you don"t wanna merge it, let"s close the PR — I don"t mind maintaining a fork.

I could help maintain this piece of logic in your repo as well if you don"t mind, just let me know.
thanks!

This is @andreynering"s decision, but I would personally vote against this for the following reasons:

• This is a large change (1500 LoC) for something that can already be achieved using other tools. These tools are always going to be more suited to their domain than Task and better supported with features etc going forwards. There are other ways to reduce boilerplate code in GitHub actions such as creating your own custom actions.
• Task"s domain is currently running commands. It does not integrate with any external tools. Opening this door is like opening Pandora"s Box. Users will expect functionality to be added for all cloud providers (AWS/Azure/GCP etc) and other integrations beyond secret management. Maintaining these features requires domain knowledge and commitment from maintainers or contributors. These commitments are very hard to make in the OSS space as people"s priorities and available free time can change very easily.
• This doesn"t follow the UNIX philosophy of "Do one thing; do it well"
• This is the first time someone has requested functionality like this. A change of this nature should require a substantial number of upvotes before being added. I don"t think adding specific functionality for 1 user is sustainable.

I totally agree with @pd93

I"ve been using Task for quite a while now and I really like its simplicity and focus on one thing, executing tasks.
I understand the desire to implement support to solve a specific user problem, Google Cloud Secret Manager, but it really opens Pandora"s Box. If Task were to start supporting other products this way, I"m afraid there would be no end to it, and this little gem would be bloated.
If the community thinks this is something Task should support then it is probably a good idea to look into some kind of plugin solution.

Keep it simple

Hi @petersamokhin,

I"m sorry, but I"m going to close this PR.

This is a significant amount of code added (and that will need to be maintained) to add just of bit of convenience.

Also, as we said, we try to add features that are more generic and will serve more users in potentially more use cases. There"s a chance that your company would be the only company really using this feature.

Integrations with specific tools are usually discarded unless for tools that are popular enough. For example, an integration with Docker may happen eventually, but that"s a very popular tool and that integration would benefit many different use cases.

You"re free to maintain a fork if you want. I"m open for questions here or on Discord if needed.

Cheers!