proposal: gp prebuild-logs Gitpod cli command
#13505
Conversation
Signed-off-by: Siddhant Khare <siddhant@gitpod.io>
|
/werft run 👍 started the job as gitpod-build-feat-gitpod-cli-gp-prebuild-logs.2 |
|
Would it make more sense for the command to print the prebuild logs to stdout instead of opening them in an editor? |
Here is the scenario. The count of Prebuild Logs depends on the number of
And, in some cases (mostly). Prebuild Logs are too long |
|
This looks interesting, @Siddhant-K-code 👀 and was an idea that we also had to support: Topic: choosing defaults
Topic: namespacing Have we considered
...etc
Topic: priority Whilst promising, let's treat this PR as low(er) priority, so that the @gitpod-io/engineering-ide have appropriate time to give feedback and test the solution before merging. Related, but we should avoid PR's without issues, as we're discussing on an active PR, where ideally this could have been discussed as an issue to get more clarity on the solution first. 🙏 |
Ok, will remember that next time. |
|
Although here is indeed many alternatives from user and implementation perspective. I wonder how we can skateboard which can be rolled back easily. How about contributing it only if latest version of IDE is selected and with experimental disclaimer in help. It does not need to be surfaced in docs and so on, but we could to use it internally or with customers via asking to choose latest and iterate. |
|
|
||
| import ( | ||
| "fmt" | ||
| "github.com/gitpod-io/gitpod/gitpod-cli/pkg/theialib" |
There was a problem hiding this comment.
We should ditch theialib. The official api is supervisor API, maybe we should think about how enrich it to return task output. We were discussing such API in the past with @geropl that dashboard could as well return output of prebuild task even if some task already finished.
I think it would be in the right direction to make prebuild UX is more reliable. cc @csweichel
|
|
||
| // initCmd represents the init command | ||
| var prebuildLogs = &cobra.Command{ | ||
| Use: "prebuild-logs", |
There was a problem hiding this comment.
How about gp prebuilds list + gp prebuilds log to list human readable names of tasks and then fetch content.
Although there is only on prebuild. I would think it should somehow resolve around tasks namespace or we need some new log namespace, for example:
> gp tasks list --prebuild
1. npm
2. gradle
> gp tasks log 2 --prebuild
log output....
but I'm not sure what would the best UX
There was a problem hiding this comment.
Currently prebuild-logs-X contains lot of things from binary characters to even process completion % (see picture here). That's why I was saying to avoid printing in terminal.
There was a problem hiding this comment.
I think they are special characters for shell and should be interpreted properly. We don't write anything else to these files besides what was produced by pty devices for shell.
| `, | ||
| Run: func(cmd *cobra.Command, args []string) { | ||
|
|
||
| const prebuildFilePath = "/workspace/.gitpod/prebuild-log-*" |
There was a problem hiding this comment.
it is implementation detail of supervisor, i think it should be a secret of supervisor how to store and fetch content. Clients should not rely on it.
loujaybee
changed the title
gp prebuild-logs Gitpod cli commandgp prebuild-logs Gitpod cli command
loujaybee
changed the title
gp prebuild-logs Gitpod cli commandgp prebuild-logs Gitpod cli command
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Important
Description
This PR Introduces the new command for Gitpod CLI,
gp prebuild-logswhich will open the Prebuild Logs File (if it exists)Related Issue(s)
Fixes #
How to test
gp preuibld-logsRelease Notes
Documentation
Yes. (will update it, after merge)
Werft options:
If enabled this will build
install/previewValid options are
all,workspace,webapp,ide