Conversation
as an exact copy of create's function
E.g. when the connection got broken, the token is wrong or the cluster is gone.
|
A single node development cluster (infra-pr-1768) was allocated in production infra for this PR. CI will attempt to deploy 🔌 You can connect to this cluster with: 🛠️ And pull infractl from the deployed dev infra-server with: 🚲 You can then use the dev infra instance e.g.: Further Development☕ If you make changes, you can commit and push and CI will take care of updating the development cluster. 🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with: LogsLogs for the development infra depending on your @redhat.com authuser: Or: |
15b1901 to
bf94f66
Compare
```
Running [/home/runner/golangci-lint-2.10.1-linux-amd64/golangci-lint config path] in [/home/runner/work/infra/infra] ...
Running [/home/runner/golangci-lint-2.10.1-linux-amd64/golangci-lint config verify] in [/home/runner/work/infra/infra] ...
Running [/home/runner/golangci-lint-2.10.1-linux-amd64/golangci-lint run] in [/home/runner/work/infra/infra] ...
Error: cmd/infractl/flavor/list/fancy.go:1:9: var-naming: avoid package names that conflict with Go standard library package names (revive)
package list
^
Error: pkg/buildinfo/buildinfo.go:3:9: var-naming: avoid package names that conflict with Go standard library package names (revive)
package buildinfo
^
Error: pkg/service/metrics/metrics.go:2:9: var-naming: avoid package names that conflict with Go standard library package names (revive)
package metrics
^
3 issues:
* revive: 3
Error: issues found
```
https://github.com/stackrox/infra/actions/runs/22721785912/job/65885650995?pr=1768#step:4:40
I did not break those, I did not even touch them.
Confirmed they started failing on no-op PR, see
#1769 and
https://github.com/stackrox/infra/actions/runs/22730204288/job/65916882489?pr=1769
Not sure why `master` wasn't affected.
Suppressing.
Used these docs
https://golangci-lint.run/docs/linters/false-positives/#exclude-issues-by-path
I tried `package blah //nolint:var-naming` but that did not work.
I did not do
```
//nolint:var-naming
package blah
```
because that would turn off the rule for the entire file.
I think the value of this test is nearly zero, but for consistency... `infractl artifacts` command goes without a test though.
infractl wait commandinfractl wait command
bf94f66 to
33243d6
Compare
davdhacs
left a comment
There was a problem hiding this comment.
+1 setting a retry limit will be useful.
|
|
||
| const ( | ||
| maxWaitErrorsFlagName = "wait-max-errors" | ||
| defaultMaxConsecutiveWaitErrors = 10 |
There was a problem hiding this comment.
defaults of 10 * 30, right? 5 minutes may be too short for the default?
There was a problem hiding this comment.
Should it default to infinite (or functionally longer than any creation will allow) to match the existing behavior? Maybe it isn't used by anyone though and this is a good point to change the default to a sane time limit.
| cmd.Flags().String("description", "", "description for this cluster") | ||
| cmd.Flags().Duration("lifespan", 3*time.Hour, "initial lifespan of the cluster") | ||
| cmd.Flags().Bool("wait", false, "wait for cluster to be ready") | ||
| common.AddMaxWaitErrorsFlag(cmd) |
There was a problem hiding this comment.
nice. I don't use the --wait. I think I don't because of it being unlimited and not being able to configure the retry interval.
Per title.
I think, it's going to be beneficial to reduce time in CI: you trigger the cluster creation without waiting, do something else, then come back and wait until the cluster is ready, then start tests.
This PR can be reviewed by commits.
Tested manually.