setup.sh failing on Ubuntu 24.04

[joshdentremont]

Not my issue, but https://islandora.slack.com/archives/CM6F4C4VA/p1721069130479709?thread_ts=1719794457.302669&cid=CM6F4C4VA

it looks like the automatic setup.sh script for isle-site-template is broken on Ubuntu 24.04. docker compose --profile dev build was unsuccessful and the setup.sh could not generate all of the secrets. The manual instructions seem to be working

[joshdentremont]

Just tested it on my mac and it works fine.

[Natkeeran]

cannot reproduce this on Ubuntu 22.04.

[joecorall]

Determined this is being caused by SSH_AUTH_SOCK not being set by default in Ubunutu 24.04, causing the generate-secrets.sh script to fail early. See slack conversation.

Apparently this SSH_AUTH_SOCK is being used for the codeserver config to help with SSH auth when pushing code changes in the container to remote git origins. We can do two things:

1. Handle this somehow for linux distros that don't have this environment variable set
2. Stop using the code server and instead just mount the codebase into the drupal container

I am highly in favor of option two. I feel we should not be forcing people to use a certain IDE in order to easily develop in the Islandora drupal stack. Mounting the codebase in dev is how I have modified the site template docker compose to work in our local instance.

[seth-shaw-asu]

Discussed in the Tech Call today. @nigelgbanks and @rosiel (not present) were noted as users of the code server. @Natkeeran mentioned others have used it for debugging PHP issues. It might be good to keep it around if someone can update that setup script to address this issue.

[nigelgbanks]

I tried looking through the chat and I didn't really see how SSH_AUTH_SOCK affects generate-secrets.sh, so I tested locally by removing the environment variable and I noticed that it had no effect.

Though I've observed that tr in the script behaves different on OSX, so I'll send up a pull for that.

[joecorall]

@nigelgbanks - this docker compose override requires the environment variable. When it's not set on linux, the script fails here: https://github.com/Islandora-Devops/isle-site-template/blob/main/generate-secrets.sh#L52

[joecorall]

@seth-shaw-asu - thanks for bringing this up at the tech call. I am sure folks have used the codeserver given this repo is designed such that it's the only way you can write Drupal code against an islandora repo running in this environment. My question for @rosiel and @nigelgbanks is whether they find it's a better developer experience than editing Drupal code from the host system. I personally find it is not, so just wanted to double check we're adding this feature for reasons other Drupal developers are finding enjoyable. If it's a desirable DX, I'm sure we can find a path forward.

@Natkeeran - if there are debugging libraries like xdebug we want to enable, that could be done without forcing an IDE choice on developers.

[nigelgbanks]

Ah I see, for me on Ubuntu 24.04 this is the output.

WARN[0000] The "SSH_AUTH_SOCK" variable is not set. Defaulting to a blank string. 
invalid spec: ::Z: empty section between colons

The failure comes from the specified bind mount options mounting no location. I think I can put a fix for this in.

[nigelgbanks]

This fixes it: #73

[nigelgbanks]

As to for this:

My question for @rosiel and @nigelgbanks is whether they find it's a better developer experience than editing Drupal code from the host system.

For me, very much so. I don't have a license for PHP Storm or the like, I don't even have PHP installed on my host system. Something like code server allows me to get in and write something with intellisense, xDebug, etc. Also, editing in the container avoids numerous problems with file permissions being different on the host, for example when doing development from Windows.

[nigelgbanks]

@Natkeeran - if there are debugging libraries like xdebug we want to enable, that could be done without forcing an IDE choice on developers.

It's not forced, it's just an easy to start with default. Especially for those folks that are not primarily developers, and do not maintain their own setup on their host system. This is a template and when forking you're free to remove the IDE, Fedora or whatever.

[joecorall]

Thanks for the PRs, @nigelgbanks. I think once #71 merges we can close this issue.

Though just to spell out my reasoning here (which is beyond the scope of this issue):

It's [codeserver] not forced, it's just an easy to start with default.

I would argue it's a difficult to start with default for most Drupal developers. The most popular local development options for Drupal (e.g. ddev) use the host IDE.

Especially for those folks that are not primarily developers, and do not maintain their own setup on their host system.

I think folks who are primarily developers is who I have in mind when talking about this. Having a different IDE when modifying code running in the site template I find much to be wanting. Most Drupal developers are working on many sites, so having one site that's special in this way I think will cause head scratching.

This is a template and when forking you're free to remove the IDE, Fedora or whatever.

Yes, technically using the codeserver is not "forced" as you can edit the docker compose YAML. One of the first things I did after installing the site template was make that change. Though I also have a solid understanding of docker fundamentals, which I wouldn't want to make a hard requirement when onboarding/introducing Drupal devs into this ecosystem. Though maybe that skillset is already baked in for most developers at this point, and this is less of a concern than I am thinking.

[nigelgbanks]

I think folks who are primarily developers is who I have in mind when talking about this. Having a different IDE when modifying code running in the site template I find much to be wanting. Most Drupal developers are working on many sites, so having one site that's special in this way I think will cause head scratching.

I see your point. Though when I've done talks at IslandoraCon, there is often a group of non-developers wanting to learn a thing or two, and it's been useful, especially in a group setting.

I would argue it's a difficult to start with default for most Drupal developers. The most popular local development options for Drupal (e.g. ddev) use the host IDE.

By the way, you can use your host IDE with the current setup (or at least you could at one point, I don't have PHPStorm to test anymore). The code-server container has SSH and you can connect to it with your host IDE as a remote target and not use the code-server in the browser.

By all means though feel free to raise a pull request adding support for ddev