github / gh-valet Goto Github PK

Valet helps facilitate the migration of Azure DevOps, CircleCI, GitLab CI, Jenkins, and Travis CI pipelines to GitHub Actions.

License: MIT License

C# 100.00%

gh-valet's People

Contributors

Stargazers

Watchers

gh-valet's Issues

[Support]: SSL error when using valet for azure devops to Github Enterprise trial org pipeline migration

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

root@ubuntuvm:~# gh valet version
gh version 2.13.0 (2022-06-22)
gh valet github/gh-valet v0.1.11
valet-cli v0.1.0.13458

What happened?

gh valet audit azure-devops -o .

error:
**13:07:28] SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate)

Relevant log output

# Logfile created on 2022-08-22 13:07:25 +0000 by logger.rb/v1.4.2
I, [2022-08-22T13:07:25.443898 #1]  INFO -- : Using GitHub Features: 'all'
I, [2022-08-22T13:07:25.444099 #1]  INFO -- : Auditing 'https://dev.azure.com/ADM-BhattUts/ADM-BhattUts/Personal/_build'
I, [2022-08-22T13:07:25.479696 #1]  INFO -- request: GET https://dev.azure.com/ADM-BhattUts/Personal/_apis/build/definitions?api-version=5.0&includeAllProperties=true&queryOrder=lastModifiedDescending
I, [2022-08-22T13:07:26.253521 #1]  INFO -- : Tracking metrics using event id '4b662c92-4cdb-4e36-8e1e-057fa25d8027'
I, [2022-08-22T13:07:26.263688 #1]  INFO -- request: POST https://valet.azurewebsites.net/api/track/metric
I, [2022-08-22T13:07:28.352923 #1]  INFO -- response: Status 200
E, [2022-08-22T13:07:28.354694 #1] ERROR -- : SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate)
/usr/local/lib/ruby/2.7.0/net/protocol.rb:44:in `connect_nonblock'
/usr/local/lib/ruby/2.7.0/net/protocol.rb:44:in `ssl_socket_connect'
/usr/local/lib/ruby/2.7.0/net/http.rb:1009:in `connect'
/usr/local/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/local/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/local/bundle/gems/faraday-net_http-1.0.1/lib/faraday/adapter/net_http.rb:138:in `request_via_get_method'
/usr/local/bundle/gems/faraday-net_http-1.0.1/lib/faraday/adapter/net_http.rb:129:in `request_with_wrapped_block'
/usr/local/bundle/gems/faraday-net_http-1.0.1/lib/faraday/adapter/net_http.rb:122:in `perform_request'
/usr/local/bundle/gems/faraday-net_http-1.0.1/lib/faraday/adapter/net_http.rb:66:in `block in call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/adapter.rb:50:in `connection'
/usr/local/bundle/gems/faraday-net_http-1.0.1/lib/faraday/adapter/net_http.rb:64:in `call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/middleware.rb:18:in `call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/response/logger.rb:25:in `call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/request/authorization.rb:51:in `call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/request/retry.rb:148:in `call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/middleware.rb:18:in `call'
/usr/local/bundle/gems/faraday-http-cache-2.4.1/lib/faraday/http_cache.rb:286:in `fetch'
/usr/local/bundle/gems/faraday-http-cache-2.4.1/lib/faraday/http_cache.rb:190:in `process'
/usr/local/bundle/gems/faraday-http-cache-2.4.1/lib/faraday/http_cache.rb:141:in `call!'
/usr/local/bundle/gems/faraday-http-cache-2.4.1/lib/faraday/http_cache.rb:121:in `call'
/usr/local/bundle/gems/faraday_middleware-1.2.0/lib/faraday_middleware/request/encode_json.rb:26:in `call'
/usr/local/bundle/gems/faraday_middleware-1.2.0/lib/faraday_middleware/response_middleware.rb:36:in `call'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/rack_builder.rb:154:in `build_response'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/connection.rb:511:in `run_request'
/usr/local/bundle/gems/faraday-1.7.1/lib/faraday/connection.rb:200:in `get'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/adapters/azure_devops/client.rb:129:in `block in fetch_all'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/adapters/azure_devops/client.rb:128:in `loop'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/adapters/azure_devops/client.rb:128:in `fetch_all'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/adapters/azure_devops/client.rb:39:in `fetch_all_pipelines'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/services/azure_devops/extract_all_pipelines.rb:18:in `block in call'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/services/azure_devops/extract_all_pipelines.rb:17:in `each'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/services/azure_devops/extract_all_pipelines.rb:17:in `call'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/commands/audit.rb:11:in `block in call'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/logger.rb:86:in `with_progress_bar'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/commands/audit.rb:10:in `call'
/usr/local/bundle/gems/valet-0.1.0.13458/lib/valet/subcommands/audit.rb:48:in `azure_devops'
/usr/local/bundle/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/usr/local/bundle/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/bundle/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/usr/local/bundle/gems/thor-1.0.1/lib/thor/invocation.rb:116:in `invoke'
/usr/local/bundle/gems/thor-1.0.1/lib/thor.rb:243:in `block in subcommand'
/usr/local/bundle/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/usr/local/bundle/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/bundle/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/usr/local/bundle/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
/usr/local/bundle/gems/valet-0.1.0.13458/exe/valet:16:in `<top (required)>'
/usr/local/bundle/bin/valet:23:in `load'
/usr/local/bundle/bin/valet:23:in `<main>'
I, [2022-08-22T13:07:28.359377 #1]  INFO -- request: POST https://valet.azurewebsites.net/api/track/exceptions
I, [2022-08-22T13:07:30.074436 #1]  INFO -- response: Status 200

Code of Conduct

I agree to follow this project's Code of Conduct

Output does not always have newline separators

Description

There have been a handful of scenarios where the output from Valet didn't buffer correctly and output gets mangled. For example:

$ gh valet audit ...
...
$ ---=---=---=---=---=---=---=--|

and

$ gh valet update
WARNING! Your password will be stored unencLogin rypted in /home/codespace/.dockerSucceeded

Add CLI command to output all version info

Description

Currently, there is a few different pieces of information needed to get all the version info needed prior to being able to debug issues. It'd be great to unify these under a single command that can be used to dump all version info to easily include it in a bug report.

For example, our support issue template currently asks for the output of gh version, gh extension list | grep valet, and gh valet version. Ideally, we could expose a command that does this all in one go:

# command name pending
$ gh valet version
gh version 2.8.0 (2022-04-13)
gh valet        github/gh-valet v0.1.8
valet-cli       v0.1.0.12760

Support darwin-arm64

When running gh extension install github/gh-valet on my mac with an m1 max CPU, I received the following error message:

gh-valet unsupported for darwin-arm64. Open an issue: `gh issue create -R github/gh-valet -t'Support darwin-arm64'`

Support darwin-arm64

[Support]: Error when updating valet using docker desktop on windows

What operating system are you using?

Linux
macOS
Windows

What version of the `gh` CLI are you using?

gh version 2.10.1 (2022-05-10)
https://github.com/cli/cli/releases/tag/v2.10.1

What version of the `gh-valet` extension are you using?

gh valet github/gh-valet v0.1.8

What version of the `valet` docker container are you using?

I get the expected first-time message:

Unable to locate Valet image locally. Please run `gh valet update` to fetch the latest image prior to running this command.

but due the issue itself I can't get the container image downloaded

What happened?

error when running gh valet update:

> gh valet update -u gabrielecalvo -p ghp_xxxxxxxxxxxxxxx
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded
Error response from daemon: unauthorized

the docker daemon is running and I can get the docker run hello-world running normally

Relevant log output

> gh valet update -u gabrielecalvo -p ghp_xxxxxxxxxxxxxxx
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded
Error response from daemon: unauthorized



### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

[Support]: Caching not working

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

gh version 2.18.1 (2022-10-20)
gh valet github/gh-valet v0.1.16
valet-cli v0.1.0.13965

What happened?

After migration from circle CI, the caching wasn't migrated quite right. I attempted to clean it up based on the official actions docs, but it seems that every build is creating its own, new cache. Even if the hashes are the same.

This is what the steps which are installing the deps and setting up the caches look like:

install_parent_deps:
    name: Install Parent Deps
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Restore Parent Dep Cache
        uses: actions/cache@v3
        with:
          key: npm-parent-${{ hashFiles('package-lock.json') }}
          restore-keys: |-
            npm-parent-${{ hashFiles('package-lock.json') }}
            npm-parent-
          path: node_modules

      - name: Install Parent Dependencies
        run: npm ci

      - name: Save Parent Cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: npm-parent-${{ hashFiles('package-lock.json') }}

  install_web_deps:
    name: Install Web Deps
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Restore Web Dep Cache
        uses: actions/cache@v3
        with:
          key: npm-web-${{ hashFiles('veoci-web/package-lock.json') }}
          restore-keys: |-
            npm-web-${{ hashFiles('veoci-web/package-lock.json') }}
            npm-web-
          path: veoci-web/node_modules
      - name: Install Web Dependencies
        run: cd veoci-web && npm ci

      - name: Save Web Cache
        uses: actions/cache@v3
        with:
          path: veoci-web/node_modules
          key: npm-web-${{ hashFiles('veoci-web/package-lock.json') }}

Any guidance here would be super helpful.

Additional info:
I also attempted to get rid of the manual caching and use the actions/setup-node@v3 to automatically set it up, but that doesn't seem to work correctly with our monorepo structure, even including a list of package.json files at the parent and each child directory.

Relevant log output

N/A - It's already been migrated, just not 100% correcrly.

Code of Conduct

I agree to follow this project's Code of Conduct

Display troubleshooting context if `update` command fails

Description

Currently, if the gh valet update command fails the user will be presented with a pretty opaque message. We should update this to provide insights into what must be done to fix their environment/issue.

If user isn't authorized

Current behavior 👇

$ gh valet update --username mona --password hunter12
Error response from daemon: Get "https://ghcr.io/v2/": denied: denied

New behavior 👇

$ gh valet update --username mona --password hunter12
You are not authorized to access Valet yet. Please ensure you've completed the following:
- Requested access to Valet and received onboarding instructions via email.
- Accepted all of the repository invites sent after being onboarded.

If token isn't permissive enough

Current behavior 👇

$ gh valet update --username mona --password valid-pat-without-correct-scopes
Login Succeeded
Error response from daemon: denied

New behavior 👇

$ gh valet update --username mona --password valid-pat-without-correct-scopes
You are not authorized to access Valet yet. Please ensure you've completed the following:
- Requested access to Valet and received onboarding instructions via email.
- Accepted all of the repository invites sent after being onboarded.
- The GitHub personal access token used above contains the 'read:packages' scope.

[Support]: Azure DevOps audit trying to pull from nonexistent, non-default branch

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

v0.1.0.13184

What happened?

I'm trying to run an audit on an Azure DevOps instance. Valet is not able to find a pipeline's yaml file, because it is looking at a branch (main) that does not exist. The file exists in the repository's default branch (dev), and the Pipeline has only ever run on this default branch + one other branch, that is not 'main'.

In the config.json output for the 2 pipelines which exist, the one that is found has

  "repository": {
    "properties": {
      "cloneUrl": "https://[email protected]/ORG/PROJECT/_git/REPO1",
      "fullName": "REPO1",
      "defaultBranch": "refs/heads/dev",
      "isFork": "False",
      "safeRepository": "REDACTED,
      "reportBuildStatus": "true"
    },

while the pipeline file which is not found has

  "repository": {
   "properties": {
     "cloneUrl": "https://[email protected]/ORG/PROJECT/_git/REPO1",
     "fullName": "REPO1",
     "defaultBranch": "refs/heads/main",
     "isFork": "False",
     "safeRepository": "REDACTED,
     "reportBuildStatus": "true"
   },

I've sanitized this input/output, the repo does indeed exist as another pipeline in the same repo is found. The yaml files are both in the root of the repo, found in the default branch which is 'dev'.

gh valet audit azure-devops -o . -g ORG -p PROJECT -t PAT

Relevant log output

[2022-07-07 17:16:10] Logs: './log/valet-20220707-171610.log'
[2022-07-07 17:16:10] Auditing 'https://dev.azure.com/ORG/PROJECT/_build'
[2022-07-07 17:16:11] There was an error extracting the Azure DevOps pipeline.
Message: There was an error retrieving file contents from Azure DevOps (https://dev.azure.com/ORG/PROJECT/_git/REPO)
Message: 404: GET 'https://dev.azure.com/ORG/PROJECT/_apis/git/repositories/REPO/items?api-version=6.0-preview&path=azure-pipelines.yml&versionDescriptor.version=main'
TF401175:The version descriptor <Branch: main > could not be resolved to a version in the repository REPO Microsoft.TeamFoundation.Git.Server.GitUnresolvableToCommitException, Microsoft.TeamFoundation.Git.Server
...
[2022-07-07 17:16:13]   ./PROJECT/REPO1 Continuous Deployment.yml
[2022-07-07 17:16:13]   ./PROJECT/REPO1 Continuous Deployment.config.json
[2022-07-07 17:16:13]   ./PROJECT/REPO1 Continuous Deployment.source.yml
[2022-07-07 17:16:13]   ./PROJECT/REPO1 CI.error.txt
[2022-07-07 17:16:13]   ./PROJECT/REPO1 CI.config.json

Code of Conduct

I agree to follow this project's Code of Conduct

[Support]:

What operating system are you using?

Linux
macOS
Windows

What version of the `gh` CLI are you using?

gh version 2.12.1 (2022-06-09)

What version of the `gh-valet` extension are you using?

N/A

What version of the `valet` docker container are you using?

N/A

What happened?

I want to enroll in private preview and try gh-valet.

Relevant log output

No response

Code of Conduct

I agree to follow this project's Code of Conduct

Check if `valet-cli` container is current

Description

We should add a check before running docker commands in the valet-cli image to see if the version that is running locally is up-to-date with the image in GHCR with the latest tag. If it is not up-to-date, then a console message should be displayed nudging users to run gh valet update.

E.g.

$ gh valet audit azure-devops -o output
A new version of Valet is available. To update, run gh valet update
...

[Support]: Support required

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

gh version 2.14.3 (2022-07-26)
gh valet github/gh-valet v0.1.12

What happened?

[platform@dgm010af8 ~]$ docker pull ghcr.io/valet-customers/valet-cli:latest
Error response from daemon: denied

I work for Albertson's and its GitHub enterprise customer, I was trying to pull docker image however it was throwing above error.

Relevant log output

[platform@dgm010af8 ~]$ docker pull ghcr.io/valet-customers/valet-cli:latest
Error response from daemon: denied

Looks like unauthorized user

Code of Conduct

I agree to follow this project's Code of Conduct

[Support]: undefined method `[]' for nil:NilClass

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

0.1.0.13168 (27eaf8ab1f68c1c9dcfcf665a52ba6f1a5686504)

What happened?

When executing an audit of pipelines from ADO, several pipelines fail with the following error:
Message: undefined method `[]' for nil:NilClass

I believe the customer is executing this in windows, but using WSL prompt.

Relevant log output

There was an error extracting the Azure DevOps pipeline.
Message: undefined method `[]' for nil:NilClass
/usr/local/bundle/gems/valet-0.1.0.13168/lib/valet/services/azure_devops/pipeline/extract_pipeline.rb:46:in `extract'
/usr/local/bundle/gems/valet-0.1.0.13168/lib/valet/services/azure_devops/extract_all_pipelines.rb:20:in `block (3 levels) in call'
/usr/local/bundle/gems/valet-0.1.0.13168/lib/valet/models/thread_collection.rb:7:in `block in perform_later'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/safe_task_executor.rb:24:in `block in execute'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/synchronization/mutex_lockable_object.rb:47:in `block in synchronize'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/synchronization/mutex_lockable_object.rb:47:in `synchronize'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/synchronization/mutex_lockable_object.rb:47:in `synchronize'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/safe_task_executor.rb:22:in `execute'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/ivar.rb:169:in `safe_execute'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/future.rb:55:in `block in execute'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:352:in `run_task'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:343:in `block (3 levels) in create_worker'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:334:in `loop'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:334:in `block (2 levels) in create_worker'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `catch'
/usr/local/bundle/gems/concurrent-ruby-1.1.10/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `block in create_worker'

Code of Conduct

I agree to follow this project's Code of Conduct

Create forecast subcommand for GitHub

The forecast subcommand was added for GitHub in the Valet repo and the subcommand needs to be added to the gh-valet repo as well

YAML files in multiple branches

Hey guys

Not sure if this is the correct place for this, is there a way to use valet on multiple branches?

I have a repo that has .gitlab-ci.yml is multiple branches for different purposes, but valet only looks in main.

Can this be done or will it be supported in the future?

[2022-10-28 11:06:44] Logs: '.\Documents/log/valet-20221028-110644.log'
[2022-10-28 11:06:44] Auditing 'https://gitlab.com/testing'
[2022-10-28 11:06:46] Resource not found
(GET 404) Not Found: https://gitlab.com/api/v4/projects/testing%2FREPO/repository/files/.gitlab-ci.yml?ref=master
[2022-10-28 11:06:46] Output file(s):==========================================|
[2022-10-28 11:06:46] .\Documents/testing_/REPO/error.txt
[2022-10-28 11:06:46] .\Documents/workflow_usage.csv
[2022-10-28 11:06:46] .\Documents/audit_summary.md

Progress bar persists on the console after command finishes

When running a command that uses progress bars, the progress bar sometimes persists on the command line after the command exits:

$ gh valet audit ...
...
$ ---=---=---=---=---=---=---=--|

[Support]: Cannot run valet commands

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

gh valet v0.1.17

What happened?

Hey team

I tried running gh valet audit, forecast, migrate etc and the command just hangs and doesn't do anything. And it does not provide any errors or logs.

Tried on 2 separate computers that are having the same issues and I also tried WSL Ubuntu on those machines and the commands work.

I hope its something that I may have overlooked, not sure if there is something I am missing, but I have everything required installed on both computers.

Any help would be appreciated.

Relevant log output

No response

Code of Conduct

I agree to follow this project's Code of Conduct

Join or use gh-valet

What operating system are you using?

Linux
macOS
Windows

What version of the tool are you using?

N/A

What happened?

I would like to get access to gh-valet tool.

my company name is Benchmark education.

Relevant log output

No response

Code of Conduct

I agree to follow this project's Code of Conduct

Private preview?

Description

How do we sign in to the private preview?

Thanks

Support linux-386

gh-valet unsupported for linux-386\

Point to new repo

Hi! Should this repo be archived in favor of github/gh-actions-importer? Thanks!

[Support]: valet unable to detect docker daemon

What operating system are you using?

Linux
macOS
Windows

What version of the `gh` CLI are you using?

2.6.0-15-g1a10fd5a

What version of the `gh-valet` extension are you using?

gh valet github/gh-valet v0.1.8

What version of the `valet` docker container are you using?

root@terraform-server:~# gh valet version
Please ensure docker is installed and the docker daemon is runningroot@terraform-server:~#
root@terraform-server:~#
root@terraform-server:~# ps -ef | grep docker
root        1545       1  0 07:06 ?        00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
root       34745   15819  0 07:31 pts/1    00:00:00 grep --color=auto docker
root@terraform-server:~#
root@terraform-server:~# docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

root@terraform-server:~#
root@terraform-server:~# gh extension list | grep valet
gh valet        github/gh-valet v0.1.8
root@terraform-server:~#

What happened?

Installed gh valet is unable to recognize docker daemon running on the same server. As mentioned above and below:

root@terraform-server:~# gh valet version
Please ensure docker is installed and the docker daemon is runningroot@terraform-server:~#
root@terraform-server:~#

I've installed gh valet exteions as per the instructions but I don't understand what really is valet docker container and how someone get that up running?

Relevant log output

Docker version, running already on same Ubunut 20 server. 


root@terraform-server:~# docker version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:45:33 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:42 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
root@terraform-server:~#



### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

Add `--password-stdin` option to `gh valet update`

Discussed in #38

^{Originally posted by korosuke613 May 26, 2022}
gh valet update can specify --password, but this method is insecure. (I think this warning is issued by docker login.)

❯ gh valet update --username korosuke613 --password ***
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
...

But, gh-valet update does not have the --password-stdin option.

❯ gh valet update --username korosuke613 --password-stdin
Unrecognized command or argument '--password-stdin'.
...

So I would like to see the --password-stdin option add to gh valet update.

GitHub CLI version: 2.11.3 (2022-05-25)
gh-valet version: v0.1.9

Expose new `migrate` command option `--workflow-file-prefix`

Valet recently added a new CLI option for the migrate command to add a prefix to the workflow files using --workflow-file-path option. We need to reflect this change in gh-valet

Valet PR link

github / gh-valet Goto Github PK

gh-valet's People

Contributors

Stargazers

Watchers

Forkers

gh-valet's Issues

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

Description

Description

What operating system are you using?

What version of the gh CLI are you using?

What version of the gh-valet extension are you using?

What version of the valet docker container are you using?

What happened?

Relevant log output

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

Description

If user isn't authorized

If token isn't permissive enough

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

What operating system are you using?

What version of the gh CLI are you using?

What version of the gh-valet extension are you using?

What version of the valet docker container are you using?

What happened?

Relevant log output

Code of Conduct

Description

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

What operating system are you using?

What version of the tool are you using?

What happened?

Relevant log output

Code of Conduct

Description

What operating system are you using?

What version of the gh CLI are you using?

What version of the gh-valet extension are you using?

What version of the valet docker container are you using?

What happened?

Relevant log output

Discussed in #38

Recommend Projects

Recommend Topics

Recommend Org

Jobs

What version of the `gh` CLI are you using?

What version of the `gh-valet` extension are you using?

What version of the `valet` docker container are you using?

What version of the `gh` CLI are you using?

What version of the `gh-valet` extension are you using?

What version of the `valet` docker container are you using?

What version of the `gh` CLI are you using?

What version of the `gh-valet` extension are you using?

What version of the `valet` docker container are you using?