511792a62c
* Rename SetProjectName into GetProjectName Co-authored-by: Anand Singh <ansingh@redhat.com> Co-authored-by: Parthvi Vala <pvala@redhat.com> Co-authored-by: Philippe Martin <phmartin@redhat.com> * Generate specific containers.conf file for each test spec using a dedicated engine namespace Co-authored-by: Anand Singh <ansingh@redhat.com> Co-authored-by: Parthvi Vala <pvala@redhat.com> Co-authored-by: Philippe Martin <phmartin@redhat.com> * Listen on random ports on Podman when '--random-ports' is used This reduces the risks of port conflicts when running test specs in parallel. Co-authored-by: Philippe Martin <phmartin@redhat.com> * Exclude Gosec G404 (use of math/rand) rule Co-authored-by: Philippe Martin <phmartin@redhat.com> * Run Podman specs in parallel * Output the Pod spec to be played by Podman depending on verbosity level This will help debug potential issues. * Use random name in 'using devfile that contains K8s resource to run it on podman' test * Use random component name in sample java-quarkus project used in 'a hotReload capable project is used with odo dev' test * Revert "Run Podman specs in parallel" Parallelization works great on GitHub Actions, but I experimented a lot of issues when running locally with a lot (~11) of parallel test nodes. Not sure why exactly, but some containers created by Podman had a lot of networking issues. We can look into parallelizing the runs later in a subsequent PR. This reverts commit 64d5d31248a62f355a32ca245ba399a723fdb22f. * Allow overridding the number of parallel nodes for Podman integration tests This way, we could be able to run them in parallel on GitHub but sequentially (default) locally. This will still benefit us by reducing the time it takes to run such tests on GitHub. Meanwhile, we can look into the issues we have locally with parallelization. Note that it is still possible to run them locally in parallel via the PODMAN_EXEC_NODE env var. Co-authored-by: Anand Singh <ansingh@redhat.com> Co-authored-by: Parthvi Vala <pvala@redhat.com> Co-authored-by: Philippe Martin <phmartin@redhat.com>
odo - Developer-focused CLI for fast & iterative application development on Kubernetes
Overview
odo is a fast, and iterative CLI tool for developers who write, build, and deploy applications on Kubernetes and OpenShift.
Why use odo?
- Fast: Spend less time maintaining your application deployment infrastructure and more time coding. Immediately have your application running each time you save.
- Standalone:
odois a standalone tool that communicates directly with the Kubernetes API. There is no requirement for a daemon or server process. - No configuration needed: There is no need to dive into complex Kubernetes yaml configuration files.
odoabstracts those concepts away and lets you focus on what matters most: code. - Containers first: We provide first class support for both Kubernetes and OpenShift. Choose your favourite container orchestrator and develop your application.
- Easy to learn: Simple syntax and design centered around concepts familiar to developers, such as projects, applications, and components.
Learn more about the features provided by odo on odo.dev.
Installing odo
Please check the installation guide on odo.dev.
Official documentation
Visit odo.dev to learn more about odo.
Community, discussion, contribution, and support
Chat
All of our developer and user discussions happen in the #odo channel on the official Kubernetes Slack.
If you haven't already joined the Kubernetes Slack, you can invite yourself here.
Ask questions, inquire about odo or even discuss a new feature.
Issues
If you find an issue with odo, please file it here.
Contributing
- Code: We are currently working on updating our code contribution guide.
- Documentation: To contribute to the documentation, please have a look at our Documentation Guide.
We are an open community who welcomes any concerns, changes or ideas for odo! Come join the chat and hang out, ask or give feedback and just generally have a good time.
Meetings
All our calls are open to public. You are welcome to join any of our calls.
You can find the exact dates of all scheduled team calls together with sprint dates in the google calendar (iCal format).
Legal
License
Unless otherwise stated (ex. /vendor files), all code is licensed under the Apache 2.0 License.
Usage data
When odo is ran for the first time, you will be asked to opt-in to Red Hat's telemetry collection program.
With your approval, odo will collect pseudonymized usage data and send it to Red Hat servers to help improve our products and services. Read our privacy statement to learn more about it. For the specific data being collected and to configure this data collection process, see Usage data.