* 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>
* Change NewRunHandler params with Options
* Pass an options to RunHandler to show logs
* Hide spinner and std output since outputs are displayed
* Integration tests with failing command
* Fix outputs
* use raw terminal and local standard i/o streams
* Fix podman i/o
* Fix stdout/err
* Test if in/out are terminal
* command reference doc
* Add a run command
* Check command name passed as arg
* Check platform is available
* Add a Run method to the DevClient
* Run command on cluster
* Add test with run command on cluster
* Implement and test run on podman
* Enhance test to check that command has been executed in container
* Fix `odo help` test
* Refactor common code for podman/cluster
* Test Apply commands on Kubernetes/Images
* Test a msg is displayed when executing odo run without odo dev
* Review
* makes GetRunningPodFromSelector return only Running pods on Podman
* Check that the "Syncing files into the container" spinner is correctly displayed on both Podman and cluster
* Add missing "Syncing files into the container" spinner when running 'odo dev' on Podman
This indicates to the user that we are sync'ing the files,
which might be a potentially long operation.
This is to be consistent with the output when using 'odo dev' on cluster.
* Add integration test highlighting the expectations
* Record parameter (and value) set or unset using the 'odo preference set/unset' commands
By default, values are anonymized.
Only parameters explicitly declared list will be recorded verbatim.
This list is currently empty, but that might change later on.
* Mark all current preference parameters except ImageRegistry as clear-text
Co-authored-by: Philippe Martin <phmartin@redhat.com>
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add integration test highlighting the expectations
* Use the cancellable context derived from 'cmd.Context' where needed
* Introduce new 'wasTelemetryEnabled' telemetry property
This is recorded before any command is run.
And it will help determine if telemetry was
changed (e.g., from enabled to disabled),
so that we can record the event in this case.
* Send telemetry if it was enabled previously or if it is currently enabled
This is done by reading the actual telemetry setting
(either from env vars or the preferences file)
at the moment we want to record the telemetry event.
This covers cases where a command ('odo preference set ConsentTelemetry')
or an environment variable ('ODO_TRACKING_CONSENT')
updated the telemetry consent for example.
* Document current implementations of command handlers
* Add unit tests for execHAndler
* Refactor pkg/devfile/image to inject Backend as dependency
* Use same handler for kubedev/podmandev
* Fail after SelectBackend==nil only if backend is needed
* Move runHandler to dev/common
* Unit tests for runHandler
* Create a component.ExecuteTerminatingCommand
* ExecuteTerminatingCommand/ExecuteNonTerminatingCommand for Handler
* Fix calling other command types
* Consider parent group to determine if a command is terminating
* Replace component.execHandler by common.runHandler
* Remove execHandler
* Make runHandler and most of fields private and pass containersRunning to handler
* Pass containersRunning value
* deploy using common Handler
* Fix tests
* Use specific Dev/Deploy mode for Apply
* Fix cmdline for job
* Fix unit tests
* Pass appName and componentName with ctx to handler
* Move handler to pkg/component package
* Update doc
* Unit tests Deploy
* Unit tests Build
* Unit tests Run
* Unit tests PostStart
* Unit tests PreStop
* Update doc
* Fix Podman tests
* Fix hotReload on podman
* Change podman version timeout to 30s for tests
* Cleanup + fix doc
* Do not error out in port detection if any of `/proc/net/{tc,ud}p{,6}` files are missing
/proc/net/{tc,ud}p6 files might be missing if IPv6 is disabled in the host networking stack,
as reported by a user on RHEL.
Actually /proc/net/{tc,ud}p* files might be totally missing if network stats are disabled.
* Do not error out if we are not able to detect container ports bound on the loopback interface
We are already displaying a warning in such case
(saying that port forwarding might not work correctly);
so this should not prevent port-forwarding messages to be displayed.
We are already behaving this way when detecting if endpoints in the Devfile
are actually opened in the container.
A warning is displayed if any error occurs while checking this.
* fixup! Do not error out in port detection if any of `/proc/net/{tc,ud}p{,6}` files are missing
* Add integration tests highlighting our expectations
* Bump Devfile library to latest commit
f041d79870
* Expose preference that allows users to globally configure an image registry
* Return the effective Devfile view by default from the initial context
This is supposed to be read-only, so that tools can rely on it
and to the operations they need to perform right away.
Raw Devfile objects can still be obtained upon request
if there is need to update them (for example via 'odo add/remove
binding' commands.
* Pass the image registry preference to the Devfile parser to build the effective view
* Fix 'odo init' integration tests
- The test spec was actually not doing what it was supposed to do
- Now 'odo init' returns a complete Devfile, where the parent is flattened,
because the goal of 'odo init' is to bootstrap a Devfile.
Previously, 'odo init' would not download the parent referenced,
making it hard to understand the resulting Devfile.
* Document how odo now handles relative image names as selectors
* fixup! Document how odo now handles relative image names as selectors
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Revert "Fix 'odo init' integration tests"
This reverts commit 78868b03fd.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Do not make `odo init` return an effective Devfile as a result
This would change the behavior of `odo init`.
Furthermore, due to an issue [1] in the Devfile library,
it is not possible to parse some Devfiles with parents linked as GitHub URLs (like GitHub release artifacts).
[1] https://github.com/devfile/api/issues/1119
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* fixup! Document how odo now handles relative image names as selectors
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add test highlighting the issue and setting the expectations
* Add a timeout of 1s to the 'podman version' command
This command is called at dependency injection time to initialize a (nil-able) Podman client,
even if users won't use Podman at all.
As discussed, this command is supposed to be
quite fast to return, hence this timeout of 1 second.
Initially, we were using cmd.Output to get the command output,
but as reported in [1], cmd.Output does not respect the context timeout.
This explains the workaround of reading from both stdout and stderr pipes,
*and* relying on cmd.Wait() to close those pipes properly when the program exits
(either as expected or when the timeout is reached).
[1] https://github.com/golang/go/issues/57129
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Log the errors returned at dependency injection time when the optional Kubernetes/Podman clients could not be initialized
This helps debug such potential issues instead of swallowing the errors.
* Make the timeout configurable via the 'PODMAN_CMD_INIT_TIMEOUT' env var
This will allow setting a different value for environments like
in GitHub where the Podman client would take slightly more time to return
(I guess because of we are running a lot of Podman commands in parallel?).
* Increase the timeout for Podman tests to an arbitrary value of 10s
Some tests did not pass because the Podman client did not
initialize in 1s; I guess because we are running a lot of Podman commands in parallel?
This should hopefully improve this situation.
* fixup! Add a timeout of 1s to the 'podman version' command
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* On cluster, run Build command again only if Build command itself is not hotReloadCapable
* On Podman, execute Build command only if itself is not hotReloadcapable
* Handle hotReloadCapable in handler
* Add integration tests
* Update doc
* review
* Allow passing extra build flags to Podman/Docker
This is supported via 2 new env vars:
- ODO_IMAGE_BUILD_ARGS: passed when building images via Podman/Docker
- ODO_CONTAINER_RUN_ARGS: passed when running odo dev on Podman
Those are comma-separated list of options
that can be passed to either Podman or Docker
(depending on the PODMAN_CMD env var).
* Refactor 'build-images' tests to make it easier to add additional tests
* Add integration tests for passing build extra args
* Add integration tests for passing global extra args to Podman
* Distinguish between global options passed to Podman and specific options for 'podman play kube'
Previously, we were handling 'ODO_CONTAINER_RUN_ARGS' as global options for Podman,
but this turns our not being that useful if we want to pass dedicated options to 'podman play kube'.
This commit introduces a new 'ODO_CONTAINER_BACKEND_GLOBAL_ARGS' env var,
which will be used as global options passed to every Podman command we execute.
This paves the way to isolating our Podman-related tests further
using the '--root' and '--runroot' global options.
* Use `ODO_IMAGE_BUILD_ARGS` in the Advanced Guides
* Use a semicolon as delimiter for extra flags
Doing so because some of the options of Podman/Docker can actually be either repeated or comma-separated.
