On Sun, Jun 30, 2024 at 9:56 PM Nathaniel Belles <mon99keymon99...@gmail.com> wrote:
> > I'm struggling to understand the desired way to develop functionality > using this git repo. For instance, I have written my own extension and I > would like to run it with guacamole-client in a docker container. From my > current understanding, I need to get the .jar file for my extension so it > can be loaded, which means the extension needs to be in the exentions/ > folder and then built. But, if I'm trying to run this extension in the > provided docker container, I somehow need to then also load it into the > docker container. I would like to be able to track changes to my extension > in git but that requires making changes outside of just the folder with my > extension (like updating the extensions/pom.xml file to tell it to build > the extension). > > Nathaniel, I guess I'll start with a couple of more things that are more general guidance than specific answers to your questions: First, I'd highly suggest that you fork the Github repo and then manage your changes by checking out different branches of the code, rather than cloning it to Gitlab and trying to manage it there. It'll likely be easier to keep things updated from the main Apache repository, so you'll be able to make sure that you get the changes that get made to the upstream repositories into your code. You'll also be able to submit pull requests for your code back to the Guacamole repositories, contributing to the project - there may be others that find the changes you're working on beneficial, and we can help evaluate whether those changes belong in the repository or not, and get them merged. I also sense an overall lack of familiarity with git. I could be reading too much into that, so if you are familiar with git, forgive my misreading between the lines. However, if that is the case, I'd suggest finding a good primer - YouTube video, or Github documentation, or something similar - to help get more familiar with managing git repositories, branches, tags, commits, etc. > Some formulated questions: > > - How do I write code for my own extension while also having an easy > way to build and load the extension into the docker container? > > My guidance would be to: * Fork the Apache repo, then create a branch for your changes. * Make the changes in your branch. * Build the Docker image from your branch and deploy that way. > > - How do I load environment variables for my docker container so that > they can be picked up by the extension? (like I previously did here > > <https://gitlab.com/Nathaniel.Belles/guacamole/-/commit/71504e043ea8575b3d314348eb6d2dd28e2163d1#40759a3888389ca45e9116bd90d64a57c1d03210_958_958> > ) > > * In addition to the code changes you're making, also update the Docker code in guacamole-docker/build.d/010-map-guacamole-extensions.sh to map your externsion to an environment variable that will enable it and cause the extension to be linked so that it is loaded. > > - How do I track changes to my code while also being able to pull in > version changes of the main codebase? > > With git :-). I think if you follow the guidance above, forking the Github repo and then using branches, you'll be able to do this, with the following additions: * Make sure to update the "main", "next", and "patch" branches of your fork with the code from the Apache branch. You need to add the Apache branch as a second remote branch (I have added one called "upstream"), and then fast-forward merge the upstream changes to your fork (git merge --ff-only upstream/main). * Once you have those branches of your fork updated, you can rebase your branch on top of whichever one you've based it on (git rebase main). You may end up with conflicts at some point that you have to work through - this can be a messy process, but shouldn't be too frequent if you keep things updated periodically. > > - How do I test building my extension with different versions > guacamole-client (v1.5.4 vs. v1.5.5 vs. 1.6.0)? (like I previously did > here > > <https://gitlab.com/Nathaniel.Belles/guacamole/-/commit/1189a951b8b6bbe678666b450c5fd361564591c6> > and here > > <https://gitlab.com/Nathaniel.Belles/guacamole/-/commit/69e32d31af0edd6276581954d7127c45a33b993b> > ) > > I'd encourage you not to worry too much about this - just pick a place that you want to build against and go with that - worry about the other versions as we get there. Specifically: * I would not worry about building for older versions of Guacamole unless you have a direct requirement for that. We don't update or maintain older versions, so they're just going to get...old. * If you're writing new code/extensions, then it probably does not make any sense to base or build against the "patch" branch, as we won't release features with that branch. Currently this is 1.5.5. * For new features (extensions), the "main" branch is probably the best starting place, as it'll be our feature branch and the most likely place for compatible changes to get merged. The main branch still has version 1.5.5, but it is going to be our 1.6.0 release - hopefully soon. * For new features or changes that break compatibility, you can use the "next" branch. This also currently has 1.5.5 as the version, but will likely be 2.0.0. > > I have already started down the path of creating my own extension for > adding web hooks to some common authentication tasks, which I have > documented here <https://gitlab.com/Nathaniel.Belles/guacamole>. Feel > free to explore that repo to see what I've been doing and provide some > insight on how I could be doing things better. In fact, here > <https://gitlab.com/Nathaniel.Belles/guacamole/-/commit/71504e043ea8575b3d314348eb6d2dd28e2163d1> > is > a link to the commit that has the code for the extension I added (and all > the wrappers I had to add to get it to build and load all the environment > variables properly). > > Cool. I've played with that in the past, and I think it'd likely be a useful thing for people who want to send those events to a logging system or some other method via Webhooks. > As a user, I didn't like keeping two separate repos for what would be > similar software versions, so I integrated it into one repo and only pulled > the current version of the codebase at the time and everything was working > perfectly. But, as one might guess from reading this post, that the docker > containers are are no longer building and I'm looking for a better way to > develop code for this extension. I really liked setting this up because it > meant that it was very clear from the commits exactly what changes I had > made vs. changes made to the main repos. Then, I was hoping to periodically > integrate the latest changes from the main github repos to this project but > that was proving to be a difficult and dirty task with a lot of manual code > manipulation. A lot of things have changed recently to the way that docker > images are built for this repo and have made things very confusing and hard > to follow. > > I don't think you need to keep two separate repos for guacamole-client - this is what branches are for. You can check out a branch, make changes, build it, and then check out the next branch. I would not recommend combining the guacamole-client, guacamole-server, and guacamole-manual repositories into a single repository - this will likely lead you to further confusion over where the changes are coming from, especially as you try to keep track of the upstream ones. And, yes, Mike has re-tooled the Docker bits of the code recently, but it's with the goal of making it far, far easier to 1) load existing extensions (EXTENSION_ENABLED=true), and 2) add functionality and extensions in the future with minimal changes to the code. So, hopefully you don't encounter that, again, too terribly often :-). > I know that's a lot of vague questions but hopefully my general confusion > comes across. Any feedback/info would be greatly appreciated. Thanks! > > No problem at all - feel free to post back with any further questions or concerns. -Nick
