This ensures the same local address is used for listening and checking if a given port is free.
Otherwise, `net.listen("tcp", ":$port")` would listen on `0.0.0.0:$port`,
and, on some operating systems like Windows 11, `127.0.0.1:$port` is surprisingly considered as free
(see output below). This, as a consequence, made it impossible to run multiple Dev Sessions on Windows.
```
PS C:\Users\asoro> netstat -aon | grep 2000
TCP 0.0.0.0:20000 0.0.0.0:0 LISTENING 11044
TCP 127.0.0.1:20001 0.0.0.0:0 LISTENING 11044
TCP [::]:20000 [::]:0 LISTENING 11044
TCP [::1]:20000 [::1]:53656 ESTABLISHED 11044
TCP [::1]:53656 [::1]:20000 ESTABLISHED 9984
```
Using the same local address for listening and checking if the port is free would be safer.
If we decide to support passing a custom address, we would use that address instead.
* Make UI not experimental
* Display API and UI URLs
* Remove link to old sources
* Fix integration tests
* Add UI to Usage Data
* Add a "Using the GUI to edit the Devfile" page to doc
* Add link to odo.dev specific page
* Apply suggestions from code review
Co-authored-by: Armel Soro <armel@rm3l.org>
* Change favicon with odo logo
* Display web console URL as part of the Dev status
* Update UI static files
* Document that Comments not supported
* Add UI screenshots
---------
Co-authored-by: Armel Soro <armel@rm3l.org>
* Remove kubeconfig flag
* Do not check file exists from KUBECONFIG, as KUBECONFIG can be a list of files and this is done by clientcmd library
* Fix odo --help
* Add integration test to check flag is not supported
* Set Save button on top, enable it only when devfile changed
* Use snackbar to display parse errors
* Do not alert devfile modified when user clicks Save
* Update UI static files
* Do not regenerate apiserver-gen/go/routers.go
* Regenerate after changes done in pr#6989
* Do not regenerate apiserver-gen/go/logger.go
* Change logs
* Fix comments
* Remove API Server from experimental mode, set UI Server as experimental
* Adapt api-server integration tests
* Disable --api-server by default in the tests
They are enabled only if `options.StartAPIServer`
is explicitly enabled.
This is to avoid potential port conflicting issue,
especially on Windows - see [1]
[1] https://github.com/redhat-developer/odo/issues/6939
* Error out if `--api-server-port` is set but `--api-server` is false
---------
Co-authored-by: Armel Soro <asoro@redhat.com>
* Let the OS assign a random ephemeral port if `--random-ports` is specified when running `odo dev` or `odo api-server`
This should hopefully fix the potential port conflict flaky
issue we are seeing, especially on Windows.
* Do not allow setting `--random-ports` and a specific port value
This applies to:
- `odo dev --random-ports --api-server --api-server-port=<port>`
- `odo api-server --random-ports --port=<port>`
* Load Segment module
* First events
* Add GET /telemetry epoint to API
* Init telemetry with data from API
* Add more tracking
* Update ui static files
* Send telemetry for tab changes
* Update UI static files
* Set IP to 0.0.0.0
* Update UI static files
* Add '/notifications' endpoint for subscribing to server-sent events
* Generate server and client
* Try implementing the notification service endpoint
* Revert "Try implementing the notification service endpoint"
This does not seem to work because the generated server always responds
with application/json, and it is not possible to respond with a
different content-type.
This reverts commit cf3ce83677649763b8166c4847501c37246dd757.
* Revert "Generate server and client"
This reverts commit b985c007a0561edbe185adc3b9582e12aa3f072b.
* Revert "Add '/notifications' endpoint for subscribing to server-sent events"
This reverts commit c5c903329f13dbe4ec096d83b1c8624fd622bef3.
* Implement 'GET /notifications' SSE endpoint and logic to detect and notify Devfile changes
* Leverage EventSource to subscribe to Server Sent Events
Here, this is being used to automatically reload the Devfile in the YAML view
whenever the API server notifies of filesystem changes in the Devfile
(and related resources).
* Add Preference Client to apiserver CLI
This is needed to be able to persist Devfiles from the UI to the filesystem
* Add E2E test case
* fixup! Leverage EventSource to subscribe to Server Sent Events
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Limit the round-trips by sending the whole Devfile content in the DevfileUpdated event data
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* [Cypress] Make sure to wait for APi responses after visiting the home page
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Generate static UI
* fixup! [Cypress] Make sure to wait for APi responses after visiting the home page
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* refactor: Set the experimental mode env var in a single place for the '--api-server' related tests
* Add integration tests highlighting the expectations
* Make the state client return the API server ports per platform
'odo dev' might be running on both cluster and podman,
so we might end up with several API servers.
* Make 'odo describe component' return information about the API Server and web UI
This is viewable only when running 'odo describe component'
with the experimental mode enabled.
* fixup! refactor: Set the experimental mode env var in a single place for the '--api-server' related tests
* Unit-test describe#filterByPlatform logic
* Simplify logic for 'describe#filterByPlatform', as suggested in review
Co-authored-by: Philippe Martin <phmartin@redhat.com>
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Generate static UI files from within a container, for more predictability
For some reason, Angular was not generating the same hash
for the `runtime*.js` file (even with the same content),
causing the 'check-ui-static-files' job to sometimes fail.
Leveraging a container (as we are already doing for the
'generate-apiserver' and 'generate-apifront' tasks)
should allow for more predictable output.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Generate static UI
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Update 'go.mod' with new location of the Alizer library
* Downgrade and pin conflicting versions of 'github.com/docker/{cli,distributions}'
Pinning it to the version we had before.
Otherwise, there were issues when running 'go mod tidy':
```
$ go mod tidy
go: downloading github.com/operator-framework/api v0.17.6
go: finding module for package github.com/docker/docker/pkg/term
github.com/redhat-developer/odo/pkg/auth imports
github.com/openshift/oc/pkg/cli/login imports
github.com/openshift/oc/pkg/helpers/term imports
github.com/docker/docker/pkg/term: module
github.com/docker/docker@latest found
(v24.0.4+incompatible), but does not contain
package github.com/docker/docker/pkg/term
```
* Fix expected output in quickstart guides doc automation tests
* Display the supported architectures in `odo registry` output
* Allow filtering by architectures
* Update documentation accordingly
* Add test cases
* fixup! Update documentation accordingly
* fixup! Allow filtering by architectures
Devfiles with no architecture declared are supposed to be compatible
with all known architectures.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* fixup! Add test cases
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Serve UI from api server
* Build UI static files + check generation with GHAction
* Update UI static files
* Use specific commit for verify-changed-files action
* Add pkg/apiserver-impl/ui to .gitattributes
* Ignore pkg/apiserver-impl/ui/** for sonar
* Serve /devfile
* Implement /devfile endpoints
* Load/Save devfile from UI
* Required metadata fields in the response
* Add an Apply button on 1st tab
* Fix: validate new devfile, not previous one
* Add generated UI files to gitattributes file
* Fix rebase
* Add new `--run-port` flag to `odo init` to set ports non-interactively
As depicted in [1], this leverages the default (or single non-default) run command to find the linked container component.
As such, it assumes that the command found is an exec command,
and that the linked component is a container component.
[1] https://github.com/redhat-developer/odo/issues/6925
* Add unit and integration tests highlighting the expectations
* Document the new `--run-port` flag
* Fix some typos and language correctness issues in the `odo init` doc
* Add doc automation test for the output of `odo init --run-port`
This ensures the output and sample in the doc are kept in sync with the code base.
* POST /devstate/container
* Implement POST /devstate/container
* Generate DELETE /devstate/container/{containerName}
* Implement DELETE /devstate/container/{containerName}
* Serve /devstate/image
* Implement /devstate/image
* Serve /devstate/resource
* Implement /devstate/resource
* Move Components specific code to components.go
* Serve /devstate/*command
* Implement /devstate/*command
* Serve /devstate/metadata
* Implement /devstate/metadata
* Serve devstate/chart
* Implement /devstate/chart
* Create a DevfileContent schema reference
* Use `DELETE /command/{name}` instead of `DELETE /*Command/{name}`
* Serve /devstate/command/move
* Implement /devstate/command/move
* Serve /devstate/command/{name}/[un]setDefault
* Implement /devstate/command/{name}/[un]setDefault
* serve /devstate/events
* Implement /devstate/events
* Serve /devstate/quantityValid
* Implement /devstate/quantityValid
* Add json tag to API result value
* Sets a proxy for the API
* Move calls from wasm to api (first part)
* Implement PUT /devsatte/devfile
* Move calls from wasm to api (end)
* Implement GET /devstate/devfile
* Implement DELETE /devstate/devfile
* At startup, get devfile from api, not from localStorage
* Rename service wasmGo -> devstate
* Remove wasm module
* Update to latest devfile-lifecycle version, license compatible
* Apply suggestions from code review
Co-authored-by: Armel Soro <armel@rm3l.org>
* Remove wasm from ui/{Makefile/devfile.yaml}
* Define DevfileContent into apispec
* Define required fields
* Generate API models from front
* Regenerate API server after spec changes
* Fix examples case
* Fix github action e2e tests not running
* Make target for all generated api code
---------
Co-authored-by: Armel Soro <armel@rm3l.org>
* Add integration tests highlighting the expectations
* Add and fill a 'Commands' field from the DevfileData struct returned by `describe`
* Display commands in the human-readable output of 'odo describe'
* Add documentation and sample outputs
* Pass odo context to api server
* Get /instance
* DELETE /instance implementation
* Move describe logic to pkg/component/describe
* Get /component implementation
* POST /component/command implementation
* Fix example by replacing action with name
* Fix integration test
* Integration tests
* Add comment for PushWatcher
* Test DELETE /instance without --no-watch
* Apply suggestions from code review
Co-authored-by: Armel Soro <armel@rm3l.org>
* Return an error if not ready for push
* Fix windows tests
* Fix tests for Windows
---------
Co-authored-by: Armel Soro <armel@rm3l.org>
* Show podman version in odo version; TODO: fix test and implement json
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add integration test
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add support for JSON
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add documentation
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Fix missing OpenShift version
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add warnings when unable to fetch version information
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Do not print warning when --client is used and review
Signed-off-by: Parthvi Vala <pvala@redhat.com>
---------
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add test highlighting the expectations
* Propagate errors and call os.Exit only in 'main' functions
See ExitInMain[1] and ExitInMain_ExitOnce[2] coding convention guidelines.
[1] https://github.com/redhat-developer/odo/wiki/Dev:-Coding-Conventions#exit-in-main
[2] https://github.com/redhat-developer/odo/wiki/Dev:-Coding-Conventions#exit-once
* Handle errors returned by Cleanuper#Cleanup
This makes sure the exit code of the command
is mapped onto any error returned by Cleanup
* Do not return an error when the watch loop in 'odo dev' is interrupted
* Test that the exit code of 'odo dev' matches the error returned by the cleanup logic
* Add unit test highliging the issue
* Fix 'delete' unit tests
* Pass the filesystem object where it is relevant
* Add a way for CLI commands to indicate whether of not they require a valid Devfile
For the 'analyze' command, this is not required,
so Devfile parsing will be ignored completely.
* Make the fake filesystem return an absolute current dir
Otherwise, some code will assume it is relative,
and try to prepend the current physical directory
* Implement HTTP Server based on OpenAPI spec
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Starter server when odo dev starts
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add --api-server and --api-server-port flags to start API Server; write the port to stat file; TODO: make this feature experimental
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
Co-authored-by: Philippe Martin <phmartin@redhat.com>
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Make the flag experimental
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Make apiserver and apiserverport flag local
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Use container image to run openapi-generator-tool instead of a local CLI
Co-authored-by: Armel Soro <asoro@redhat.com>
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add integration test
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Use label podman
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Regenerate the api files with openapitool v6.6.0 and changes from review
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
---------
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Document the '--no-commands' flag
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add integration tests highlighting the expectations
* Add '--no-commands' flag to the 'dev' sub-command
* Implement '--no-command' on Podman
* Implement '--no-command' on cluster
* Validate the '--no-commands' flag in the CLI
For example, it should not be possible to call it alongside '--build-command' or '--run-command',
because we won't be able to know what to do.
* Fix 'odo dev' tests when the run/debug does not exist
For consistency with how e.g., the build command works,
instead of erroring out, `odo dev` will
now simply log the error message and wait for new input.
* Check for command existence when we want to run them
As suggested in review, this makes it more adaptable.
As a consequence, if the default (or single) build/run command does not exist,
"odo dev" will not error out immediately; instead, it will behave a bit like
"odo dev --no-commands" (by starting, but printing a warning about the
missing command).
The difference here is that if a run command is added later on
during the dev session, "odo dev" will pick it up and run it,
but "odo dev --no-commands" will continue to purposely ignore it.
The existence of the optional default Build is already checked
by the 'libdevfile.Build' command. It does not error out if there is
no default (or single) Build command. It errors out only if the specified
'--build-command' does not exist in the Devfile.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Check for application ports only if the Devfile has run or debug command and if there are ports to forward
This prevents:
i) displaying the "Waiting for the application to be ready" spinner for nothing,
if there are no ports to forward
ii) waiting until the timeout of 1m has expired if there was no run/debug command executed,
in which case, it is less unlikely that the application ports defined in the Devfile
will ever be reachable.
* Test "odo run" command against a Dev Session started with and without "--no-commands"
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
