Updated approach to use https://github.com/phenaproxima/xb-demo. This creates a new composer project in the drupal root using xb-demo. Then we add a Composer repository to the demo_design_system checkout as a `path`. Then we composer require the `dev-main` version constraint of demo_design_system. For this to work, we need to modify root the composer.json from `drupal/civictheme` to `drupal/demo_design_system`.
kristen pol → credited q0rban → .
volkswagenchick → credited q0rban → .
Moving to RTBC per @clarksquared
Sorry about that. Should be fixed now. Thanks for the review @longwave!
I believe this is working? I logged into the Preview, added the Responsive Table to Full HTML, and then created an article here: https://mr13-yge4knjbbyldx508tv2wv9ivs3colxkr.tugboatqa.com/
Javier mentions that there is a testing page built-in to the module. I couldn't find that.
If there is content you would like to import, that can be added to the config.yml. Just let me know what and how to do that.
q0rban → changed the visibility of the branch 3507860-tugboat-config to active.
q0rban → changed the visibility of the branch 3507860-tugboat-config to hidden.
The module is getting installed properly, however it still needs to be manually configured. We could in theory set up a test Spotify app and expose the credentials for that via environment variables, but I do wonder if someone with the admin login credentials to these previews could exfiltrate that info from the Preview, and if so, if that would create a security issue.
This appears to be working (see attached screenshot)
It is difficult to find this page when performing a web search of "drupal.org Tugboat" since the title does not contain the word Tugboat. Folks that are trying to find out how to integrate Tugboat with their contributed module or theme are shown other search results, such as the drupal.org case study and the like.
q0rban → changed the visibility of the branch 3507818-tugboat-xb-dev-standard to hidden.
q0rban → changed the visibility of the branch 3507818-tugboat-xb-dev-standard to active.
q0rban → changed the visibility of the branch 3507818-tugboat-xb-dev-standard to hidden.
Okay, that seemed to do the trick, thank you @phenaproxima!
After switching to using the ddev script, I receive the following error during composer install:
...
- Patching drupal/core
- Found cached patch at /root/.cache/composer/patches/cf81f867c053876f8a76c6be64ef23a8b207c51b00b1edaabd303fddcffc317e.patch
- Patching drupal/default_content
- Found cached patch at /root/.cache/composer/patches/2660ac03daf6d98707d4545122c3098f58445ce35da6140f3088a4b322f3ef91.patch
52 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating optimized autoload files
108 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
In ScaffoldFilePath.php line 135:
Scaffold file xb_page.yml not found in package drupal/cms.
Any ideas on what might be wrong?
Tugboat build completed successfully that time. https://mr383-wrpoaadtpuidlglhwmgprwa1iwrvnded.tugboatqa.com/
Sorry, it must have expired. I closed and reopened the MR, so it's building again. It will last 5 days.
@kristen-pol, looks like 🐛 XBEndpointRenderer adds response headers that sometimes exceed common server limits Active is in properly now, and I think our issue is fixed! Can you confirm?
I have rebuilt the Tugboat Preview. I also rebased from 0.x.
Even though [#381343] is in, it seems like we are still getting a response header over 8kb.
[Fri Nov 15 21:04:29.268970 2024] [proxy_http:warn] [pid 498:tid 508] (28)No space left on device: [client 10.0.0.109:36628] AH10124: header size is over the limit allowed by ResponseFieldSize (8192 bytes). Bad response header: 'Attach-Settings: {"ajaxPageState":{"theme":"xb_stark","theme_tok[...]refix":"","currentPath":"xb-field-form\\/node\\/1","currentPathIsA', referer: https://mr323-wxhia2wxtwznpslehfq0oh9fqczoqr9s.tugboatqa.com/xb/node/1/component/ea7bb6e5-fbf8-481c-9e7e-1200d1d739f7
[Fri Nov 15 21:04:29.269211 2024] [proxy_http:warn] [pid 498:tid 508] [client 10.0.0.109:36628] AH01106: bad HTTP/1.1 header returned by /xb-field-form/node/1 (GET), referer: https://mr323-wxhia2wxtwznpslehfq0oh9fqczoqr9s.tugboatqa.com/xb/node/1/component/ea7bb6e5-fbf8-481c-9e7e-1200d1d739f7
I reopened [#381343] since it seems like the MR didn't get merged in.
Is it possible that this didn't get merged in? I'm still seeing the large response headers on the 0.x branch, and it looks like MR 401 is still open.
@kristen-pol, now that 🐛 XBEndpointRenderer adds response headers that sometimes exceed common server limits Active is in, I've recreated the Tugboat Preview here. I tried to replicate the issue we were encountering before, but it seems like enough has changed that I'm not sure how to do so. Can you take a look to see if you can replicate? Thank you!
Do we consider 🐛 XBEndpointRenderer adds response headers that sometimes exceed common server limits Active a blocker to this issue?
Thanks for debugging. Not sure what I we can do on the SDDS end... anything?
I'm not sure! Do you know what is setting those response headers? Is it coming from SDDS or Experience Builder? Or something else?
Thank you for the video, that was very helpful in replicating the issue!
It seems that this is an issue with Apache rejecting the response due to response headers being too large:
[Sat Oct 12 18:34:23.700729 2024] [proxy_http:warn] [pid 26575:tid 26588] (28)No space left on device: [client 10.0.0.52:49552] AH10124: header size is over the limit allowed by ResponseFieldSize (8192 bytes). Bad response header: 'Attach-Settings: {"ajaxPageState":{"theme":"stark","theme_token"[...]\\u0022storage\\u0022:{\\u0022target_type\\u0022:\\u0022media\\u0022},', referer: https://mr323-zbzg3fgtmxhjnhiibdr2ns38ldwjk3r8.tugboatqa.com/xb/node/1/component/d81c9a76-cd42-4297-bda1-d669d7e26d3a
While the HTTP spec doesn't specifically limit the size of headers, it is common for many proxies to limit header sizes to 8KB. For that reason, it might be best to transfer any data in the response itself, rather than in headers.
I wonder if this is a permissions issue. I've just pushed up a change that might fix that. Can you test again, Kristen?
Thank you!
@kristen at the top of this issue, you will see a "View live preview" button, and if you click that button, you can test there. Credentials are admin/admin.
Follow-up issue: ✨ Demo Experience Builder button on project landing page Active
Closing this issue since the initial Tugboat config is in.
I'll open another issue for a "Demo 0.x" button based on the discussion from #35.
Thank you, that did the trick.
Updated MR.
Note, this increases the build time to about 10 minutes.
Thank you @alexpott!
Since we are already using drush for the current Tugboat preview integration, do you think it would acceptable to continue to use it until such a time as there is support for #37 in core's install command? Or do you see that as a blocker to this task?
@q0rban Based on #40, it sounds like #35 is not possible?
It's not something built into the drupal.org integration presently, though I do really like the idea. This took a few hours to cobble together using the Tugboat API, nodejs backend, and react frontend, and does basically what you are asking for, albeit for the 0.x of drupal_cms → . We could host something similar for this module, but I'd much rather have something built-in to d.o so that anyone could do it, if we can get the DA's support and some drupal dev help. What do you think?
The previews expire after 5 days. To recreate it, you can close the MR and reopen it.
If that still doesn’t fix it, make sure the branch for the MR has the tugboat config in it.
If you close and reopen the MR, a new preview will get created.
Okay, interesting. I don't see a "civic" theme in there. Should I use the "starshot_demo" theme?
I made an MR for this, but the preview gives a WSOD. The error is:
Uncaught PHP Exception Twig\\Error\\LoaderError: "Template "starshot_demo:starshot-hero" is not defined in "themes/contrib/demo_design_system/starshot_demo/templates/page--front.html.twig" at line 4." at /var/www/drupal/vendor/twig/twig/src/Loader/ChainLoader.php line 111
Any ideas?
Would you like the demo_design_system theme to be the default theme, or just installed and available?
Thank you! Feedback addressed. Over to @effulgentsia.
Switching composer repository to use path instead of vcs which simplifies the config.
I made the change to path instead of vcs. It required modifying the composer stability to dev. So now the module in Drupal is a symlink to the git checkout. It simplified the config, so thank you for the recommendation.
Oh, maybe because I am using vcs instead of path. I didn't know about that option! That seems like it would simplify things for sure. I'll check it out. Thank you @effulgentsia!
The short answer is yes, each new MR would have a preview with the changes that are in the MR applied.
The long answer requires an explanation of some of the steps in the config.yml. These steps come from https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... → .
We are using drupal/recommended-project and using composer to require the MR branch into it. The way we are achieving that is as follows:
First, we create a branch that we can reference later. We use the unique Tugboat repo ID as the branch name so that we don't accidently conflict with a real branch that a contributor may have:
# Check out a branch using the unique Tugboat ID for this repository, to
# ensure we don't clobber an existing branch.
git checkout -b $TUGBOAT_REPO_ID
Then, inside the composer root of drupal/recommended-project, we set up a composer repository to point to the git checkout of the MR, and composer require experience_builder using the unique branch name above:
# We configure the Drupal project to use the checkout of the module as a
# Composer package repository.
composer config repositories.tugboat vcs $TUGBOAT_ROOT
# Now we can require this module, specifying the branch name we created
# above that uses the $TUGBOAT_REPO_ID environment variable.
composer require drupal/experience_builder:dev-$TUGBOAT_REPO_ID
I believe using composer instead of a symlink is better, as you can be sure that any composer scripts are run as they would for an end-user. These are also the same steps that other d.o Tugboat integrations are using with success, so using them adheres to the principle of least astonishment for anyone else who may contribute to this config.yml in the future.
I am open to ideas and suggestions for improvement!
Setting COMPOSER_MEMORY_LIMIT to -1 is unnecessary as it is built-in to the Docker images.
Okay, I think I fixed that issue. I'm still not entirely sure what I'm looking for to see if it's working.
Ah, interesting, I think I see what's going on. The module is being pulled into drupal/modules using composer + git, but I am running those npm commands inside of the checkout of the module, not the composer-installed location.
One change that might be useful in .tugboat/config.yml is doing nvm install instead of nvm use, which will not only install the specificed Node.js version, but will also start using it.
nvm install is being run in the init command group: https://git.drupalcode.org/project/experience_builder/-/merge_requests/2...
#13 implies that the npm run build command is failing (or isn't getting reached). Is there a way to see a log of what Tugboat outputs when it runs the nvm use, npm install, and npm run build commands?
Thank you, @effulgentsia. Here is the output of npm run build. Any clues there?
Run npm install
. /root/.nvm/nvm.sh
cd $TUGBOAT_ROOT/ui
nvm use
npm install
npm run build
Found '/var/lib/tugboat/ui/.nvmrc' with version <20>
Now using node v20.17.0 (npm v10.8.2)
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm warn deprecated @humanwhocodes/object-schema@2.0.3: Use @eslint/object-schema instead
npm warn deprecated @humanwhocodes/config-array@0.11.14: Use @eslint/config-array instead
npm warn deprecated @babel/plugin-proposal-optional-chaining@7.21.0: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-optional-chaining instead.
npm warn deprecated @babel/plugin-proposal-numeric-separator@7.18.6: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-numeric-separator instead.
npm warn deprecated @babel/plugin-proposal-nullish-coalescing-operator@7.18.6: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-nullish-coalescing-operator instead.
npm warn deprecated @babel/plugin-proposal-class-properties@7.18.6: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-class-properties instead.
npm warn deprecated @babel/plugin-proposal-private-methods@7.18.6: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-private-methods instead.
added 982 packages, and audited 983 packages in 42s
202 packages are looking for funding
run `npm fund` for details
2 moderate severity vulnerabilities
To address all issues, run:
npm audit fix
Run `npm audit` for details.
npm notice
npm notice New patch version of npm available! 10.8.2 -> 10.8.3
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.8.3
npm notice To update run: npm install -g npm@10.8.3
npm notice
> vite-template-redux@0.0.0 build
> npm run type-check && vite build
> vite-template-redux@0.0.0 type-check
> tsc --noEmit --pretty
vite v5.3.1 building for production...
transforming...
✓ 1041 modules transformed.
rendering chunks...
computing gzip size...
dist/index.html 0.53 kB │ gzip: 0.33 kB
dist/assets/index.css 704.40 kB │ gzip: 85.65 kB
dist/assets/index.js 693.58 kB │ gzip: 227.21 kB
(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
✓ built in 7.62s
This makes a more or less explicit dependency on drush working with HEAD at all time no?
Yes, that is true… and that is already the case with the current Tugboat integration for core. We've had it working this way for the past several years, and it's not been a problem. I'm open to suggestions if there are other ways to install Drupal from scratch programmatically! ☺️
Thank you @balintbrews. I pushed up a fix to install nodejs and run the npm commands. Did that fix things? I'm not sure how to test.
On a side-note, this is my first time working with nvm, it's not really tailored for CI environments, is it? I couldn't find docs for using it in CI. Seems like it's more geared for human usage with a logged-in shell. Definitely open to suggestions if I'm doing something silly.
Thank you @abhisekmazumdar
What version of nodejs should be used for those npm commands?
Okay, I think I've got this working with help from @marcoscano, if someone could add him as a contributor to this. I'm not sure how to do that.
I'd be willing to help out with this, though I do not know anything about Experience Builder.
Ideally we would have the node/1 created there by default so that all you would have to do is to log in and navigate to Experience Builder.
Is there a programmatic way you typically do this, or is this usually a manual task (logging in via the browser to create the node)?
(Credentials are admin/admin if you would like to log in)
@phenaproxima, thank you for the review! You should see a link under the MR to the preview. Once this is merged in, that link will show on any MRs.
@smustgrave we needed to rebase the branch, that's why the build was failing. It built correctly now.
Updating preferred docker image for Tugboat config.yml.
Add a line to the config.yml update phase to add Tugboat URLs to the Drupal trusted host patterns.
Juampy (or someone with appropriate access) might need to close and reopen the MR for the Tugboat preview to get built.
Hmm, how do I change the target branch of the MR?
Add link to Tugboat QA drupal.org welcome page.
Document how to create a Tugboat Base Preview for a new drupal core development branch.
I am open to having other maintainers, but it has been many years since I've maintained anything in Drupal contrib, I would need someone else with more recent Drupal experience to vet any potential maintainer.
+1
Update recommended config.yml to describe how to modify minimum-stability requirements.
mherchel → credited q0rban → .