If you’re getting “PHP out of memory errors”, you can manually set the memory limit higher. If you’re using one of the tugboatqa php images, use something like this in your build script:
echo "memory_limit = 512M" >> /usr/local/etc/php/conf.d/tugboat.ini
If you would like unlimited memory allocated to PHP command-line scripts, you can add the following PHP snippet to your application:
if (PHP_SAPI === 'cli') {
ini_set('memory_limit', '-1');
}
Or when executing PHP directly:
php -d memory_limit=-1 path/to/php-script.php
If you’re getting a “MySQL server has gone away” error, you can often resolve this by increasing the packet size for MySQL.
To increase the max_allowed_packet to 512MB you can add the following command to your MySQL service in the Tugboat
config.
mysql -e "SET GLOBAL max_allowed_packet=536870912;"
If you want this setting to persist after the build process, you can also add that setting to a MySQL cnf file that is
added to the init command
group of your MySQL service.
echo "max_allowed_packet=536870912" >> /etc/mysql/conf.d/tugboat.cnf
Here is an example Tugboat config implementing the above techniques.
services:
mysql:
...
commands:
init:
# Increase the allowed packet size to 512MB.
- mysql -e "SET GLOBAL max_allowed_packet=536870912;"
# Ensure this packet size persists even if MySQL restarts.
- echo "max_allowed_packet=536870912" >> /etc/mysql/conf.d/tugboat.cnf
Each command is run in its own context,
meaning things like cd do not “stick” between commands. If that behavior is required, include an external script in
the git repository and call it from the config file.
Add your build steps to a file; for example: .tugboat/init.sh
#!/bin/sh
cd somewhere
run-a-command
Call that script from config.yml for the build step:
commands
init: .tugboat/init.sh
Or, as a part of the build step:
commands:
init:
- /some/command
- .tugboat/init.sh
- /some/other/command
This error occurs when a command in your config file can’t be executed, or returns an error. When a Preview build fails with this error:
If you’re having trouble pinpointing the error, you may need to go back and execute your config file commands line-by-line until you find the point at which things stop working.
A few common problems in config files include:
cd does not “stick” between commands and
running a background process “breaks” the build. Check out the troubleshooting docs for
info on addressing these issues.
If you’ve gone through the debugging process and haven’t been able to figure out why your command is failing, reach out to us at help and support - we’re happy to take a look!
If you’re getting this error message, it’s because you haven’t enabled the repository setting to allow building pull requests from forks.
This setting is off by default, but when it’s enabled, Tugboat builds Previews for pull requests made to the primary repo from forked repositories. Turning on this setting should correct this error.
When you enable this option in a public repository, anyone who can submit a pull request from the fork can extract configured repository environment variables, as well as the private SSH key generated for the repo. The latter is mainly a problem when the repository SSH key is added to some other service, like to pull a database or checkout a related git repo. However, as an example, if the repository SSH key is allowed to push changes to a git repo, a malicious user would then have access to modify that repo.
If you try to add a background-process to your config file in the conventional way, Tugboat will think the Preview has not finished building, and it will be stuck in the “building” state until it eventually times out and fails.
For instructions on how to run a background within a Tugboat Preview, see: Setting up Services -> Running a Background Process.
If you’ve created a script that “sleeps” in the background while a Preview is being built, but that script is missing when the Preview build completes, that’s an expected behavior. When a Preview build completes, Tugboat stops the containers to take the build snapshot. After the data is committed, Tugboat restarts the containers to serve the Preview. Any scripts that were waiting for the build to complete will no longer be present when the container is restarted.
To create a one-time script that runs after the Preview build completes, take a look at
runit’s documentation - particularly the parts about creating a finish
script.
Some Tugboat users have run into a case where they expect to see GitHub repositories in Tugboat, but those repositories appear to be missing. There are a couple of ways this condition could manifest, and the fix for it depends on why the GitHub repositories aren’t visible.
If Tugboat has previously been authorized, but that authorization is revoked or expires, you’ll no longer see an organization’s repositories in Tugboat’s “Create a Repo” form. Our support team was able to take these steps to reproduce the issue:
Expected Behavior is that the new repository would show up in the list of available repos in Tugboat’s “Create a Repo” form. However, the authorizing org must take extra steps on the GitHub side to restore the repositories. This state can occur if someone at the authorizing org mistakenly revokes Tugboat’s authorization, but it also appears to be a known issue for some products that use GitHub OAuth in integrations.
Short-term, the workaround for this issue is:
Now, the organizations and their repositories should appear in the Tugboat UI.
If this still doesn’t fix the issue, some users have had success with revoking and re-connecting GitHub to Tugboat.
A different condition can cause a similar result; when you go to Tugboat’s “Create a Repo” form, if you don’t see a repository you expect to see, it may be because an organization can’t or won’t grant organization-level OAuth authorization. If you need to use an alternative method to authenticate with a git provider, see: Connect with Your Provider -> Authenticating using an API access token.