More rework

This commit is contained in:
crschnick 2024-06-09 13:40:09 +00:00
parent 94a0791880
commit ecb8a68937
7 changed files with 59 additions and 9 deletions

View file

@ -78,6 +78,7 @@ public class StoreToggleComp extends SimpleComp {
StoreViewState.get().toggleStoreListUpdate();
});
});
t.tooltipKey("showAllChildren");
t.value.subscribe((newValue) -> {
val.set(newValue);
});

View file

@ -195,7 +195,7 @@ public class StoreEntryWrapper {
var branch = p.getBranchDataStoreCallSite();
if (branch != null) {
if (branch != null && entry.getStore() != null && branch.getApplicableClass().isAssignableFrom(entry.getStore().getClass())) {
return branch.getChildren().stream().anyMatch(child -> {
return showActionProvider(child);
});

View file

@ -85,7 +85,7 @@ public class StoreSection {
}
seen.add(wrapper);
var found = list.getList().stream().filter(section -> wrapper.getEntry().getOrderBefore().equals(section.getWrapper().getEntry().getUuid())).findFirst();
var found = list.getList().stream().filter(section -> section.getWrapper().getEntry().getUuid().equals(wrapper.getEntry().getOrderBefore())).findFirst();
if (found.isPresent()) {
return count(found.get().getWrapper(), seen);
} else {

View file

@ -107,6 +107,8 @@ public interface ActionProvider {
ObservableValue<String> getName(DataStoreEntryRef<T> store);
String getIcon(DataStoreEntryRef<T> store);
Class<T> getApplicableClass();
}
interface BranchDataStoreCallSite<T extends DataStore> extends DataStoreCallSite<T> {
@ -124,8 +126,6 @@ public interface ActionProvider {
Action createAction(DataStoreEntryRef<T> store);
Class<T> getApplicableClass();
default boolean requiresValidStore() {
return true;
}

View file

@ -1,3 +1,51 @@
This is an experimental implementation of an HTTP server to provide an API for XPipe that is easy to use and access. The existing interface used by the CLI has been completely ported over to that, so there might be a few behavior changes for the CLI.
## A new HTTP API
## It is not recommended to use this version for now unless you're interested in development.
There is now a new HTTP API for the XPipe daemon, which allows you to programmatically manage remote systems.
You can find details and an OpenAPI spec at the new API button in the sidebar.
The API page contains everything you need to get started, including code samples for various different programming languages.
To start off, you can query connections based on various filters.
With the matched connections, you can start remote shell sessions for each one and run arbitrary commands in them.
You get the command exit code and output as a response, allowing you to adapt your control flow based on command outputs.
Any kind of passwords and other secrets are automatically provided by XPipe when establishing a shell connection.
There will be more functionality added to the API in the future, for now this initial implementation is open for feedback.
## Service integration (Professional feature)
Many systems run a variety of different services such as web services and others.
There is now support to detect, forward, and open the services.
For example, if you are running a web service on a remote container, you can automatically forward the service port via SSH tunnels, allowing you to access these services from your local machine, e.g. in a web browser.
These service tunnels can be toggled at any time.
The port forwarding supports specifying a custom local target port and also works for connections with multiple intermediate systems through chained tunnels.
For containers, services are automatically detected via their exposed mapped ports.
For other systems, you can manually add services via their port
## Script rework
The scripting system has been reworked. There have been several issues with it being clunky and not fun to use. The new system allows you to assign each script one of multiple execution types. Based on these execution types, you can make scripts active or inactive with a toggle. If they are active, the scripts will apply in the selected use cases. There currently are these types:
- Init scripts: When enabled, they will automatically run on init in all compatible shells. This is useful for setting things like aliases consistently
- Shell scripts: When enabled, they will be copied over to the target system and put into the PATH. You can then call them in a normal shell session by their name, e.g. `myscript.sh`, also with arguments.
- File scripts: When enabled, you can call them in the file browser with the selected files as arguments. Useful to perform common actions with files
If you have existing scripts, they will have to be manually adjusted by setting their execution types.
## Docker improvements
The docker integration has been updated to support docker contexts. The UI has also been streamlined to make common actions more easily accessible.
Note that old docker container connections will be removed as they are incompatible with the new version.
## Better connection organization
The toggle to show only running connections will now no longer actually remove the connections internally and instead just not display them.
This will reduce git vault updates and is faster in general.
You can now order connections relative to other sibling connections. This ordering will also apply when changing the global order in the top left.
## Other
- The Linux installers now contain application icons from multiple sizes it should increase the icon display quality
- The Linux builds now list socat as a dependency such that the kitty terminal integration will work without issues
- Searching for connections has been improved to show children as well
- The welcome screen will now also contain the option to straight up jump to the synchronization settings

View file

@ -473,3 +473,4 @@ api=API
storeIntroImportDescription=Already using XPipe on another system? Synchronize your existing connections across multiple systems through a remote git repository. You can also sync later at any time if it is not set up yet.
importConnections=Sync connections
importConnectionsTitle=Import Connections
showAllChildren=Show all children

View file

@ -8,12 +8,12 @@ info:
You can change the port of it in the settings menu.
Note that this server is HTTP-only for now as it runs only on localhost. HTTPS requests are not accepted.
The main use case for the API right now is programmatically managing remote systems.
This allows you to programmatically manage remote systems.
To start off, you can query connections based on various filters.
With the matched connections, you can start remote shell sessions for each one and run arbitrary commands in them.
You get the command exit code and output as a response, allowing you to adapt your control flow based on command outputs.
Any kind of passwords another secret are automatically provided by XPipe when establishing a shell connection.
If required password is not stored and is set to be dynamically prompted, the running XPipe application will ask you to enter any required passwords.
Any kind of passwords and other secrets are automatically provided by XPipe when establishing a shell connection.
If a required password is not stored and is set to be dynamically prompted, the running XPipe application will ask you to enter any required passwords.
You can quickly get started by either using this page as an API reference or alternatively import the [OpenAPI definition file](/openapi.yaml) into your API client of choice.
See the authentication handshake below on how to authenticate prior to sending requests.