Conversation
Development with devcontainers can be problematic. `pixi` environments are light weight.
* A developer's guide * An operator's guide * A roadmap * An index (could be rolled into the top level README.md)
installed as flatpaks
The commit adds robust setup tools and improves file permission handling: - Add gp-setup script for automated system configuration - Add gp-welcome script with setup guidance and status checks - Switch to user-specific runtime directories instead of /var/run - Add proper permission validation and error messaging - Support both root and non-root deployment modes - Add test scripts and conda package improvements - Document runtime directory selection and setup process
The use of rpm-ostree to provide the missing webkit libraries does not actually work reliably. I am working on making conda packages for the missing libraries.
configuration management Maybe have a workflow task which creates them if needed.
Better to check in the same location.
There was a problem hiding this comment.
Pull Request Overview
This PR overhauls the build and packaging workflows by adopting a Pixi-based setup, adds cross-platform installation scripts and conda packaging recipes, and provides comprehensive test suites along with developer and operator guides.
- Introduce Pixi tasks and update
pixi.tomlfor build, test, package, and publish workflows. - Add shell scripts for installation, environment setup, task running, and version override.
- Provide extensive end-to-end tests and AsciiDoc documentation for developers and operators.
Reviewed Changes
Copilot reviewed 60 out of 72 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tests/test-task-refactoring.sh | Add strict naming convention test suite for Pixi tasks |
| tests/test-gp-setup-logging-fix.sh | Validate gp-setup logging permission fixes |
| scripts/task-runner.sh | New enhanced task runner with logging, workflows, and error handling |
| pixi.toml | Define Pixi project config, dependencies, and task definitions |
| recipe.yaml | Conda recipe for full application package build |
| recipe-cli.yaml | Conda recipe for CLI-only package build |
| scripts/create-gp-version-override.sh | Generate LD_PRELOAD library for GlobalProtect version override |
| docs/sects/*.adoc | Developer and operator guide sections added/updated |
Comments suppressed due to low confidence (3)
tests/test-gp-setup-logging-fix.sh:96
- The grep pattern uses a literal '$USER' instead of expanding to the actual username, so the test for a user-specific log file will always fail. Change the pattern to "/tmp/gp-setup-$USER.log" without escaping the dollar sign.
if grep -q "/tmp/gp-setup-\$USER\.log" "$gp_setup_script"; then
packaging/files/usr/lib/NetworkManager/dispatcher.d/gpclient-nm-hook:43
- The comment refers to
gpclient, but the code sends SIGUSR2 to the gpservice PID. Update the comment to match the actual process being signaled or adjust the signal target if incorrect.
# Send a USR2 signal to the gpservice process to resume the VPN connection
scripts/task-runner.sh:179
- The workflow references
show-package-info, but no such task is defined in Pixi (it should beshow-package-status). This will cause the workflow to fail at runtime.
tasks=("clean" "build-cli" "test-cli" "package-cli" "show-package-info")
|
@phreed Thank you very much for enhancing the project. I will review it gradually. |
I have it to the point where it works for me on my bluefin system. I was able to correct some longstanding problems:
I am going to stop working on it now. I might come back to this when the openconnect issue 807 is resolved and propagated to conda-forge. And you are very welcome, thanks for making this. |
|
I prefer to use pixi over devcontainers (though pixi can certainly be used in a devcontainer). Key differences and use cases between Scope of controlPixi focuses on managing the software packages and their versions within your existing operating system or container. Dev Containers, on the other hand, provide a completely isolated and pre-configured environment, Setup complexitySetting up a Pixi environment is often less complex than a Dev Container, especially for basic use cases. Resource usageDev Containers can be more resource-intensive due to running a separate operating system, |
|
pixi is a new thing to me, but it looks modern. I will learn it and try to integrate it based on your work. |
Yes, pixi is very new. |
|
Where are we at with this? Do you need something from me? |
|
Hi @phreed, thank you for your work on this. I just wanted to mention that I'm not currently full-time on this project—apologies for any delays in my responses. I tested the gp-version-override feature and noticed that it may not be functioning as expected. Specifically, while the |
Hi, @yuezk , GP VPN working.
https://github.com/phreed/GlobalProtect-openconnect
git clone git@github.com:phreed/GlobalProtect-openconnect.git gpoc
cd gpoc
git checkout vanderbilt
pixi run build-cli
./vanderbilt-vpn For more information look in https://github.com/phreed/GlobalProtect-openconnect/blob/vanderbilt/docs/gpclientw-wrapper-guide.adoc |
|
That branch has a bunch of vanderbilt specific stuff so I will need to back the changes into this PR. p.s. I know you are busy and I would appreciate your thoughts. |
|
Hi @phreed, I really appreciate your contribution! Your PR motivates me to learn more about the Pixi build and the monkey patching mechanism. Although I still couldn't override the After learning the code, I believe that the Pixi build system is modern and can achieve the same goal that I did with the Makefile and the dev container. However, I'm concerned that it cannot be used to build release packages for different Linux distributions because it requires online installation and internet access to download dependencies during the build process. When releasing the DEB/RPM packages, the build machine cannot access the internet, and we can only use the tools and dependencies from their own package managers' repositories. Therefore, we cannot use the Pixi build system to create release packages for different Linux distributions. Considering this, I am unable to introduce the Pixi build system. Otherwise, we have to maintain two build systems for the same project, which is not a good practice. In addition to the Pixi-related changes, I will incorporate some of your other changes in future releases. Thank you again for your contribution! |
|
Are you saying that the building of the DEB/RPM are happening on machines with the proper packages pre-loaded? |
Not really. It is not the GitHub CI job. It is the distribution's CI machine, for example, the Ubuntu's Launchpad and the OpenSUSE's Build Service. These services don't allow access to the internet. We also need to support different architectures (i.e., x86_64 and aarch64). So it may not be that easy to prepare the package. |
|
@yuezk I am considering packaging the command line application as a conda-forge package. Here is an example of a substantial illustrative package (both command-line and GUI):
As you can see it has variants for multiple architectures and operating systems.
I realize you have a liberal license for the command line version, so, that is the part I am thinking of packaging. Note:: I generally run FCOS based systems so installing application level packages (*.rpm *.deb) is not something I do. |
Got the idea, this is much easier to achieve. Publishing the CLI to the conda-forge and user can install it with related package manager, e.g., pixi. |
2 participants
I am attempting to use your system with our campus network.
I made a number of significant changes.
I hope you like some of them.
pixibuild, while the devcontainer approach works it can be clumsy I have provided a brief comparison below.pixiworks well with conda packages. I have added a rattler-build task and recipe.yaml for building the package.With these changes and those below it now work with our university servers.