Problem this feature will solve

Not a problem just a nice to have.

Background

Some like color in their terminal and others dont.

Proposed Solution

colorize the spinner and the init summary to really catch your eye but not be too crazy.

Constraints and Assumptions

ANSI 256 required

Alternatives or Workarounds

Be boring and live in a world of black and white.

Additional context

color is good for the soul ;)

Describe the bug

During a first run of a workspace the preview browser is opened way before the system is ready to display any content

Steps to reproduce

1. Create a new workspace from this repo using Theia as your editor. In starter.ini, ensure a front end scaffolding like react is used.
   The preview browser opens and refreshes while project scaffolding is still being set up

Expected behavior

The preview browser should open only after all code in the init command has finished.

Additional information

Describe the bug

The image-workspace.log is displayed before the rest of the init messages

Screenshots

Steps to reproduce

Create a new workspace:
The workspace-image.log and init messages that are not yet in a log are lost in a jumble of yarn, gem, and artisan installs.

Expected behavior

workspace-image.log and the soon to come workspace-init.log #21 should be displayed last in the init process, after the output for all the installs, alias writing, moving of files etc.
Init messages should still be displayed in realtime in the midst of the other installs however for the sake of clarity they should also be displayed in compact form at the very end of the process, along with the output of the the workspace-image.log.

Additional information

This issue is blocked by #21

Problem this feature will solve

Gitlog on its own is not robust enough. We need status for refacotring, adding libraries, etc..
Also:
Often all the unstaged changes need to be commited in groups, not all at once. for example 1 changed file and 1 new file. The new file needs to commit message prefic "NEW" while the changed file may need a status of "FIX"

Background

See:

• gitlog
• Gitmoji's emoji list

Proposed Solution

• Add additional status like REFACTOR, ADD, WIRE, COMMENT
• add a seperate set of aliases that just set the commit message, no git add and no git push

Constraints and Assumptions

<! -- Any constraints and/or assumption relevant for the development and use of this feature? -->

Alternatives or Workarounds

Additional context

Add any other context or screenshots about the feature request here.

Describe the bug

There are extranoues yarn installs and laravel mix compiles happening when more than one optional install from starter.ini is set.

Screenshots

Steps to reproduce

set phpmyadmin and react to install, there will be three total calls to yarn install and laravel mix.

Expected behavior

yarn install and laravel mix could be called alot less. once if there are not optiona installs and twice if there are multiple optional installs. maybe even just once for all of it.

Additional information

An API for getting installation information from starter.ini should be built into bash/helpers.sh and used for this feature.
has_installs: echos 1 if anything is installed, echos 0 if otherwise
has_only_phpmyadmin_install: echos 1 if only phpmyadmin is installed but no frontend scaffolding is installed, echos 0 if otherwise
has_only_frontend_scaffolding_install: echos 1 if no phpmyadmin is installed and at least 1 frontend scaffolding is installed.

Describe the bug

The very first time the workspace is built and the workspace image is craeted then whatever value is set for the install for phpmyadmin in starter.ini will be respected. However on subsequent creations of the gitpod workspace this phpmyadmin install value will only be respected if the workspace image is rebuilt. The workspace image is cached and will only rebuild if there is a significant change to the .gitpod.Docker file.

Screenshots

Steps to reproduce

1. Set the install value for phpmyadmin in starter.ini to 1. Push that change to your repository.
2. Create a Gitpod workspace from your repository for the very first time.

• phpmyadmin is successfully installed

3. Set the install value for phpmyadmin in starter.ini to 0. Push that change to your repository.
4. Create another Gitpod workspace from your repository.

• phpmyadmin is still installed.

Expected behavior

When the install value for phpmyadmin in starter.ini is set to 0 and the a new Gitpod workspace is created then phpmyadmin should not be installed.

Workaround

You can workaround this issue by incrementing the value of ENV INVALIDATE_CACHE in .gitpod.Dockerfile. This will force the build of a new workspace image.

Describe the bug

Once the project A.K.A. scaffolding (Laravel, phpmyadmin, etc.) files are created and pushed to the repository they are needlessly copied into repository in the IDE everytime the gitpod workspace is created. This causes git conficts and confusion and can potentially overwrite a users work.

Screenshots

Not at this time.

Steps to reproduce

1. Create a new Laravel 8 starter repository on github.
2. Create a new gitpod workspace using the repository created in step 1.
3. Push Laravel scaffolding (project files) and any other pending changes to the remote repository either using the a terminal or the GUI (in the IDE).
4. In the gitpod dashboard delete the workspace created in step 2.
5. Create a new workspace using the repository created in step 1 that you updated in step 3.

Expected behavior

Subsequent creation of gitpod workspaces from a project copied from https://github.com/apolopena/gitpod-laravel8-starter that already has the scaffollding pushed to its repository should not have that scaffolding copied into the repository again. In other words once scaffolding has been pushed, it should never be copied into the repo again.

Additional information

Not at this time.

Describe the bug

When logging into phpmyadmin a seciruty warning shows near the bottom of the page.

Screenshots

Steps to reproduce

log into any phpmyadmin installation in a project from this starter.

Expected behavior

Security warning should not display

Additional information

Describe the bug

After project scaffolding is saved to the repo during the first workspace image build, subsequent rebuilds of the workspace image which may contain new scaffolding such as phpmyadmin, do not copy over. Also project scaffolding is created and copied over blindly even if it already exists which results in data loss.

Screenshots

Steps to reproduce

For the no vendor folder problem

1. Create a fresh workspace of this repo
2. Save project scaffolding to the repo
3. Create a fresh workspace from the repo
4. Force a rebuild of the workspace by incrementing the value for INVALIDATE_CACHE in .gitpod.Dockerfile

The vendor folder is no longer present and the project will not run.

For the existing front end scaffolding gets overwritten problem

1. Create a fresh workspace of this repo, ensure no front end scaffolding is installed by default (see starter.ini)
2. Save project scaffolding to the repo
3. Modify starter.ini to install react
4. save files to repo
5. Create a fresh workspace with the repo
6. Add a comment to resources/js/app.js (this content of the comment arbitrary)
7. Save files to the repo
8. Create a fresh workspace from the repo

The comment in `resources/js/app.js will be gone.

Expected behavior

Any new files created in the project scaffolding phase via .gitpod.Dockerfile such as the vendor folder or public/phpmyadmin should be copied over only if they do not already exist. Furthermore any scaffolding created during the init phase such as scaffolding created directly in the project folder (i.e react) should only be copied over if that scaffolding does not already exist in version control.

Additional information

Switch from mv to rsync so that all new files and directories will be copied over from ~/test-app

• Hook to determine if laravel/ui has already been installed: composer show | grep laravel/ui >/dev/null && __ui=1 || __ui=0
• Hook to determine if a node package such as react already exists. Use this for detecting existing frontend scaffolding already in version control.

node_package_exists () {
  [ -z $2 ] && local path='node_modules' || local path="$2/node_modules"
  ls "$path" 2>/dev/null | grep -w $1 >/dev/null 2>&1 && echo "1" || echo "0"
}

Problem this feature will solve

No standardized way to add project specific bash code during the init command in .gitpod.yml.

Background

A non-poweruser will appreciate a standardized place to write their project specific bash code such as php artisan migrate and php artisan db:seed. The built in scaffolding for logging and using the spinner will be helpful too

Proposed Solution

Add a placeholder/scaffolding file called init-project.sh to the init command in .gitpod.yml
Scaffolding this file should include log functions exmaple patterns to use the spinner and log success and failures to the console and or /var/log/workspace-init.log

Constraints and Assumptions

<! -- Any constraints and/or assumption relevant for the development and use of this feature? -->

Alternatives or Workarounds

Write your own project specfic bash code, just make sure you put it in the right place.

Additional context

Even power users may appreciate this.

Describe the bug

When a workspace is stopped and restarted. ~/.rake is blasted away and so is anything written to ~/.gitconfig. In fact any files that are written in the init phase that are not in /workspace (or deeper) will not be there on subsequent startups of the workspace.
A seperate but related issue is that also the initialization log /var/log/workspace-init.log turns into a zero byte file on subsequent starts of a workspace because the docker image writes that file empty and expects the init task to populate it, which it does.... once..... /var/log/workspace-image.log is fine because the docker image writes to it. /var/log/xdebug.log is fine to be reset on every startup aswell unless we wanted to log to persist between startups of the workspace.

UPDATE: this bug has been addressed in Feature #31

td;LR Anything that is written to ~/ from anywhere will not persist.

Screenshots

Steps to reproduce

1. Create a new workspace
2. Stop the workspace
3. Start the workspace
4. run: git a and the output is:

git: 'a' is not a git command. See 'git --help'.

The most similar commands are
        add
        am

5. run ls ~/.rake and the output is:

ls: cannot access '/home/gitpod/.rake': No such file or directory

Expected behavior for running git a

Output for (at a minimum) should be:

alias.aliases config --get-regexp '^alias\.'
alias.a config --get-regexp '^alias\.'
alias.cap !f() { git add .; git commit -m "$@"; git push; }; f
alias.new !f() { git cap "📦 NEW: $@"; }; f
alias.imp !f() { git cap "👌 IMPROVE: $@"; }; f
alias.fix !f() { git cap "🐛 FIX: $@"; }; f
alias.rlz !f() { git cap "🚀 RELEASE: $@"; }; f
alias.doc !f() { git cap "📖 DOC: $@"; }; f
alias.tst !f() { git cap "🤖 TEST: $@"; }; f
alias.brk !f() { git cap "‼️ BREAKING: $@"; }; f
alias.lg log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Expected behavior for running ls ~/.rake

Output (at a minimum) should be:
changelog.rake

Additional information

Currently and unfortunately Gitpod does not persist anything in ~/ (/home/gitpod).

The hack here could be to take out anything that parses, copies or write new files to ~/ and move that into a before task in .gitpod.yml (UPDATE: this worked for the git aliases and the rake tasks).

before tasks run before the init command but unlike the init command before tasks run everytime the workspace is started so take that into consideration.

A system for persisting files needs to be devised.

Problem this feature will solve

multitail can crash silently when run in a terminal window that is way too small. Aditionally in most situations the user is prompted to hit a key in the terminal to continue in order to lauch multitail because multitail is so finiky about the size of terminal it is run in.

Background

This feature stems from #53

Proposed Solution

Add the ability to configure your apache log monitor in starter.ini to something like grc tail /var/log/apache2/error.log /var/log/apache2/access.log
add a variable in the development section of starter 'starter.ini' named apache_log_monitor that accepts the values tail and multitail

Constraints and Assumptions

the tail call will depend on grc
Use a custom color configuration for grc

Alternatives or Workarounds

Do it manually on every creation of a workspace every time multitail fails

Additional context

tail is too ugly without something like grc to brighten the day ;) but it does now support multiple files.
Users may still want to use multitail however since it is prone to crashing silently and was never designed to run in a Docker container, offer a colorized tail.

Describe the bug

When a workspace image is built there will be many errors flashing through the log regarding the installation of php

Screenshots

No but here is a sample of the error output

Setting up php7.4-common (7.4.3-4ubuntu2.4) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline

Steps to reproduce

1. Force a new build of the workspace image for a fork of this project or any porject created from this project,
2. Look closely at the workspace build log output flashing by in the browser

You will notice may errors like this:

debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)

Expected behavior

There should not be any errors in the log like the ones mentioned in this bug.

Additional information

This issue seemingly appeared without any code changes to warrant it so marking it as a gitpod internal bug. This fix will be a work around it by simply removing the sudo apt-get install -y php-dev command from .gitpod.Dockerfile since it seems we never needed it in the first place as these things are installed in the base image workspace-full.

Problem this feature will solve

The commands debug-on and debug-off only work for the PHP development server.

Background

The PHP development server used to be the only webserver option but now apache will be the default web server.

Proposed Solution

We need commands to enable debugging for apache as well

• Change the aliases debug-on and debug-off to be functions that take an argument of the web server either apache or php
• Gracefully handle invalid server types.

Constraints and Assumptions

Now with more than one command for toggling debugging requests, the preview browser in the IDE will change to the web server that the debug-on or debug-off was given for. This may be desired for some users and a suprises.

Alternatives or Workarounds

Edit the url manually to toggle the xdebug step debugger.

Additional context

Add any other context or screenshots about the feature request here.

Implement this fix

Implement this fix/enhancement.

On the first run in gitpod, notify the user in the console log if node_modules is empty and a package.json file is found. Then install node packages.

Describe the bug

Laravel scaffolding created via the docker container is called test-app before it is conditionally rsynced to the project repo. This is a misleading name.

Steps to reproduce

N/A

Expected behavior

The scaffolding in the temporary location should have a more meaningful name

Additional information

The scaffolding folder created by the docker container should have a more meaningful name like scaffolding or 'initial_projector eventemp-app`.

Private emails (in github, not sure about bitcuket or gitlab) or using git from the command line in gitpod may require some troubleshooting such as ammending the users email in ~/.gitconfig. Give the user some tips.

most likley private emails from github without opting out of the "Block command line pushes that expose my email" seeting will get this error when trying to push to remote from Gitpod. Either opt out or write in your private emaill addres(norepl@blahblah) to ~/.gitconfig for every worspace your create.

 ! [remote rejected] main -> main (push declined due to email privacy restrictions)

Problem this feature will solve

There is no CHANGELOG.md. Creating a Changelog by hand is hard to standardize and maintain and is time consuming especially when new releases come out quicky.

Background

Versioning a project with a detailed, neat and, standardized changelog is an important task. This process is time consuming to do by hand. Tracking changes for releases all one one tidy page is a must have for a well organized project.

Proposed Solution

• Implement github-changelog-generator
• Make the ruby gem install for this silent and quick (omit doc generation) but display a spinner in the terminal.
• Add a rake task for generating CHANGELOG.md without having to pass it any flags, simply run: rake changelog
• The rake task should accept for any flags that github-changelog-generator supports.
• Add a dynamic system to create rake tasks based on starter.ini and gitpod env vars.
• Automatically derive github user and the github project.
• Allow for configuration of --user, --project, --since_tag, and --future_release by default

Constraints and Assumptions

• Support just github for now.
• Requires ruby and as awesome as Gitpod is, the Gitpod environment comes with ruby and rake right out of the box.
• CHANGELOG will require a (git) tag in order to properly output the version number. set this tag as the value for future_release in starter.ini or the most recent changes in the changelog will have a title of UNRELEASED.

Alternatives or Workarounds

Compile changelogs by hand. This will make it almost impossible to standardize though.

Additional context

Time saved doing chores is time gained fixing bugs and coding features 💪🏽

Describe the bug

Currently there is a log for the building of the workspace image which is displayed in the init terminal however now that most optional installs are handled in .gitpod.yml the workspace-image.log gets lost in a sea of output as various packages are installed, also importants messages about success and failur regardint he optional installs gets lost in the sea of output.

Screenshots

Steps to reproduce

build a new workspace

Expected behavior

In the init terminal after any optional installs, the file paths to workspace-image.log and gitpod-init.log should be displayed

Additional information

Currently there is no gitpod-init.log, it needs to be added.

Problem this feature will solve

The starter is too rigid. There are no options to configure the Laravel project differently or with ancillary libraries such as phpmyadmin

Background

Adding a starter configuration will add flexiblity that users need.

Proposed Solution

Use environment variables to control how the starter project is created and what libraries are installed along with it.
For now just start with the ability to optionally install phpmyadmin

• Put configuration options in an env file named .starter.env. UPDATE; use a .cfg or .ini file for non sensitive configurations.
• Have another file named .example.starter.env that show available configration options
• Keep the majority of optional installs and configurations in the creation of the workspace image (.gitpod.Dockerfile)
  -- UPDATE: .env files wont work for sensitive information because all data need to come from the repo and we dont want to store sensitive data in the repo. However gitpod does have a way to store persistant evn variable across workspaces for a specfic repo or for all repos. See this.

Constraints and Assumptions

• Testing work done in .gitpod.Dockerimage is time consuming as the entire workspace image built must be forced and monitored to check results.
• Adding configuration for MySql credentials might be tricky since that information is setup in the workspace-mysql image.

Alternatives or Workarounds

If parsing MySql Creditials proves too kludgy, Instructions for changing them on the command line can be given in the readme.

Additional context

Not at this time.

Problem this feature will solve

Version info for this repo is unavailable.

Background

Every robust project should have a changelog

Proposed Solution

Now that the project has autogenerating CHANGELOG capabilities #23 lets use it.

Constraints and Assumptions

None

Alternatives or Workarounds

None

Additional context

None

Problem this feature will solve

Any file not written to /workspace or deeper is not persisted between subsequent startups of a workspace.
Because of this, on every subsequent startup of the workspace:

• ~/.gitconfig has to be re-customized
• All dynamically created rake tasks have to be re-created
• /var/log/worspace-init.log gets blasted away.

Background

See bug #30

Proposed Solution

Its hacky but until Gitpod supports file persistence outside of the `/workspace' directory let's do this:

1. Dynamically create a place to temporarily store persistent files for the project. So for example /workspace/my-project would have a ancillary folder called /workspace/my-project--store.
2. create a mark-as-inited helper function to be called once from bash/init-complete.sh as the very last line of code. The mark-as-inited function will set an is_inited.lock file (in the ancillary folder) that will serve as a flag for the workspace to know when it has already been started at least once already.
3. Create ais-inited helper function to use as a hook (that checks for the presence of is_inited.lock) for determining if the workspace has been started before or not.
4. Create a persist_file helper function that will copy the file passed in to it, to the ancillary project folder mentioned in bullet point 1. That folder will be created on-the-fly if it does not already exist.
5. Create a restore_persistent_files helper function that will copy all file 'persisted' by the persist_file function from the ancillary project folder to their original locations.
6. In bash/before-tasks.sh , right before the mark_as_inited function call. Set any persistent file you want by passing them to the persist_file function.
7. In before-tasks.sh as the very last code block, check if the workspace has been run for the first time and if it has, restore all persistent files by calling restore_persistent_files. The code will look like this:

if [ $(bash bash/helpers.sh is_inited) == 1 ]; then
  bash bash/helpers.sh restore_persistant_files $GITPOD_REPO_ROOT
fi

Constraints and Assumptions

• File persistence will work with single files but not an entire file tree. Yet...
• This 'file persistence' system is rigid and somewhat hardcoded but code be made more pliable. Not sure if its worth it right now though.

Alternatives or Workarounds

Unsure.

Additional context

Don't use this system too much because there is a bunch of boilerplate code that goes with it and eventually it will be a depricated system when Gitpod adds a file persistence feature.

Problem this feature will solve

Allowing for use of the emoji-log standard for git commits on the command line in Gitpod will standardize communication regarding git commits.

Background

Standardization of git commits is a great workflow option to have in a Gitpod environment or anywhere.

Proposed Solution

write git-log aliases into ~/.gitconfig

Constraints and Assumptions

A system for adding advanced aliases to git ~/.gitconfig will need to be devised and tested.

Alternatives or Workarounds

Write the emoji-log aliases into ~/.gitconfig everytime a workspace is created. This works but no one will do it.

Additional context

Not at this time.

Problem this feature will solve

The query parameter used to trigger debugging gets in the way for a number of reasons.

Background

Proposed Solution

Remove the query parameter after toggling debugger functionality.
Allow for either the query param to show or for it to be removed from the url.

Constraints and Assumptions

Give the nature of the gp binary, this will need to be a double refresh which might be a little clunky, it will need to be tested out a bit to ensure its a good user experience

Alternatives or Workarounds

1. Open an external preview browser.
2. Remove the query parameter from the URL.

Additional context

Add any other context or screenshots about the feature request here.

Describe the bug

Laravel Mix generates some files (for development) that should not be pushed to the repo as they will cause conflicts between developers.
Add these to the .gitignore

/public/css
/public/build
/public/mix-manifest.json

Screenshots

Steps to reproduce

Push the generated project scaffoding to your repo
Run yarn run dev
public/js/app.js will have changes in it.

Expected behavior

All Laravel Mix artifact files should be in .gitignore

Additional information

Describe the bug

The project has no .gitignore file and even if it did it would be overwritten by the project scaffolding.
Add a .gitignore to the repo and merge the project scaffolding .gitignore into it durint the Gitpod init phase.

Screenshots

Steps to reproduce

Expected behavior

Additional information

Problem this feature will solve

Currently default phpmyadmin credentials are store in version control. This is a security risk.

Background

Sensitive data such as user credentials should be kept out of version control

Proposed Solution

Put default values for sensitive data such as phpmyadmin user credentials into the file default.starter.env
If the user does not set these variables in their Gitpod account (in settings), then use the default values.

Constraints and Assumptions

Implement this for phpmyadmin
Later on any sensitive information such as data for the laravel .env file can use this pattern.
phpmyadmin env vars will only be used if phpmyadmin has been install.

Alternatives or Workarounds

Every workaround is a security risk

Additional context

To add environment variables open your Gitbpod account in a browser go to settings follow the intuitive UI.

Problem this feature will solve

Laravel forces 4 space indents in all files (PSR2). Javascript and other developers often want 2 spaces as the default and 4 spaces in *php files to conform to PSR2 or PSR12 standards. If a developer is not saavy on the .editorconfig system, they may wonder why some of their editor project settings (such as tabSize) are not being respsected.

Background

Laravel is opinionated, it writes in a .editorconfig. Sometimes developers need more flexibility.

Proposed Solution

Add a configuration in starter.ini to leave the Laravel default .editorconfig alone, use a pre-built .editorconfig that stick to PSR2/12 standards for all files but only php files use an indent of 4 spaces., or give the option to use not .editorconfig file at all (delete it).

Constraints and Assumptions

# valid values are:
# laravel-default: use the .editorconfig that comes with the laravel project scaffolding
# laravel-js-2space: altered vesrion of laravel-default allowing for 2 space indents for most files. 
#     --> see: bash/snippets/editorconfig/laravel-js-2space
# none: delete .editorconfig. Do not enforce project wide editor settings.
# Note: if left blank or set to an invalid value, laravel-default will be used

Alternatives or Workarounds

This feature is only for developers that dont want to think about granular configuration of project wide editor formats.

Problem this feature will solve

More of a nice to have.

Background

always nice to see pretty log with a single function call

Proposed Solution

Display the contents of /var/log/workspace-image.log and /var/log/workspace-init.log via a function written into ~/.bashrc

Constraints and Assumptions

256 ANSI colors used.

Alternatives or Workarounds

> cat /var/log/workspace-image.log && cat /var/log/workspace-init.log

Describe the bug

If you have a .gitignore file created by this starter project in version control, redundant data will be merged into this file and .gitignore can easily end up being pushed back to the repo with that redundant information

Steps to reproduce

1. Create a brand new prjoect using this starter project
2. After the first run on gitpod, push all the new files to the newly created project repo
3. Create a new workspace with the newly created project repo

Check .gitignore, it will contain redundant data.

Expected behavior

.gitignore data should not be merged blindly.

Additional information

Challenge: The very first .gitignore could contain anything and there is not really a decent 'hook' to know if the .gitignore in the initial laravel scaffolding created via the docker container should be merged with the project's .gitignore.
All said it probably makes sense to simply include data in the laravel scaffolding .gitignore to the project's .gitignore by default and remove the 'merge' logic in bash/init-gitpod.sh.

Describe the bug

Apache will start but the multitail of the apache log will not display when a terminal window is too small

Screenshots

Steps to reproduce

Expected behavior

Additional information

Problem this feature will solve

Any password or username that needs to be setup during creation of a cworkspace must be kept in version control.

Background

Currently this is an issue for the phpmyadmin setup.
Never keep sensitive data in version control

Proposed Solution

support a .starter.env where sensitive data can be loaded as a variable and then unset when that data is not longer needed.
Implement a system where:

• A set of values can be loaded from key value pairs set in .starter.env
• Sets of passwords (1,2,3,4 etc..) can be updated via an single alias loaded into .bashrc via .bash_aliases
• Update phpmyadmin super user and control user via a single alias named update_pma_pws

Constraints and Assumptions

.starter.env will always on the git ignore list
any valid name value pairs should be described in the file .example.starter.env

Alternatives or Workarounds

Nothing secure

Additional context

.start.env should probably only be used for the workspace initialization phase. Maybe in the init logs let the user know that for additional security they can delete the .starter.env file

Describe the bug

When you log into phpmyadmin you see the following warning at the bottom of the page
The phpMyAdmin configuration storage is not completely configured

Screenshots

Steps to reproduce

1. Fork or copy this repo
2. make sure phpmyadmin is set to install in starter.ini
3. Force the workspace image to build by incrementing the for INVALIDATE_CACHE in .gitpod.Dockerfile
4. Pushes changes to the repo
5. Create a new workspace in Gitpod
6. Log into phpmyadmin

Expected behavior

There should be no warnings and all phpmyadmin features should be setup programatically upon initialization of the workspace

Additional information

Helpful steps can be found here.

Describe the bug

After building a new workspace image you get the following error when trying to start apache.

(2)No such file or directory: AH02291: Cannot access directory '/var/log/apache2/' for main error log
AH00014: Configuration check failed
Action 'start' failed.
The Apache error log may have more information.

Screenshots

Steps to reproduce

1. Create a new github project from this starter as per the instructions in README.md
2. Force the workspace image to build
   • In .github.Dockerfile increment the value for INVALIDATE_CACHE
3. Push the changed files to the repository.
4. Create a new workspace in gitpod
5. After the IDE is displayed start apache
   • In a terminal run start_apache

You will see the error:

(2)No such file or directory: AH02291: Cannot access directory '/var/log/apache2/' for main error log
AH00014: Configuration check failed
Action 'start' failed.
The Apache error log may have more information.

Expected behavior

Apache should start.
/var/log/apache2 should be created by default when the workspace image is built.

Additional information

This is an internal gitpod bug and the fix is awaiting review.
gitpod-io/workspace-images#362

Workaround

Write the directory and files in .gitpod.Dockerfile

RUN sudo mkdir /var/log/apache2 \

    && sudo chmod 755 /var/log/apache2

RUN sudo touch /var/log/apache2/access.log \

    && sudo chmod 666 /var/log/apache2/access.log

RUN sudo touch /var/log/apache2/error.log \

    && sudo chmod 666 /var/log/apache2/error.log

RUN sudo touch /var/log/apache2/other_vhosts_access.log \

    && sudo chmod 666 /var/log/apache2/other_vhosts_access.log

Problem this feature will solve

Since this is a configurable starter project it would be nice to have the ability to optionally install react and or vue and or bootstrap. We should be able to set the version and a flag to install the files for auth logins.

The version numbers should support Semantic Versioning.
An empty value for a version means no specific version will be set, rather use whatever version laravel/ui uses

Background

The current starter installs vanilla laravel so there is no react for the front end. Furthermore Laravel 8.x has some pretty hectic defaults as far as the learning curve goes (tailwindCSS. Jeststream, Breeze, inertia.js, only vue) and there is not out of the box option for react. With this system in place a user can use tools they are more familiaar with but keep all the great features core of Laravel 8.x

Proposed Solution

add the following configuration options to starter.ini

[react]
install=1
auth=0
version=

[vue]
install=0
auth=0
version=

[bootstrap]
install=0
auth=0
version=

• 0 = true and 1 = false
• If a value for version is not set then the version that laravel/ui installs by default will be used.
• The react install supercedes the vue install
• react and vue installs come with bootstrap so they supercede a bootstrap install
• In starter.ini. auth and version are ignored if install is set to 0
• • The auth value will be ignored for bootstrap when either react or vue are installed.
• install must either be set to 0 or 1 for any optional install

Constraints and Assumptions

Use laravel/ui:^3.2.0 since it is a legacy library now in Laravel 8.x

• Installation of react will also install react-dom of the same version as specefied for react in starter.ini
• Using artisan ui to install react and vue will also bring along alot of other packages. It will be at the users disgression to remove or upgrade and of them. Here is a typical list of packages from package json when react (without auth) is installed:

    "devDependencies": {
        "@babel/preset-react": "^7.0.0",
        "axios": "^0.21",
        "bootstrap": "^4.0.0",
        "jquery": "^3.2",
        "laravel-mix": "^6.0.6",
        "lodash": "^4.17.19",
        "popper.js": "^1.12",
        "postcss": "^8.1.14",
        "react": "16.14.0",
        "react-dom": "^16.2.0",
        "sass": "^1.15.2",
        "sass-loader": "^8.0.0"
    }

Alternatives or Workarounds

Install these packages manually.

Additional context

This feature should great deal flexibility to the starter and attract a wider user base. Users can get nitty gritty with the system and craft it as they like because that is the beauty of Laravel, however allowing and 'old school' front end swap like react and bootstrap to use in Laravel 8 in place of Breeze or Jeststream will be really handy. Less learning curve if you are familiar with a bootstrap react front end stack.

Problem this feature will solve

Starting and stopping apache is hassle. Commands are a too long to type and memorize when swapping between web servers. Also its not clear when the apache server is stopped because the multitail that was spawned for it does not close.

Background

The user may need to swap between webservers (php built-in webserver, apache2 etc.). These webservers may also need to be run in parallel or all stopped at once.

Proposed Solution

Add an functions in .bashrc from `.gitpod.Dockerfile

1. Start apache2 with multitail for apache2 log and error log
2. Stop apache2 and the multitail that was spawned for it.
3. Start the PHP dev server
4. Stop the PHP dev server

Constraints and Assumptions

Add functions to .bashrc from `.gitpod.Dockerfile

Alternatives or Workarounds

None worth mentioning

Additional context

This will setup a new system of writing functions to .bashrc from the bash/snippets/ directory

Problem this feature will solve

Lots of react projects will use react-router and react-router-dom

Background

Proposed Solution

Add an install configuration option to starter.ini for react-router, this will also install react-router-dom.

Constraints and Assumptions

<! -- Any constraints and/or assumption relevant for the development and use of this feature? -->

Alternatives or Workarounds

Additional context

Add any other context or screenshots about the feature request here.

Describe the bug

Laravel/React projects fail to load app.css and ap.js when running the apache server.
Note: Project functions normally when running the php dev server or `php artisan serve'

Screenshots

Steps to reproduce

• Use apache as your server
• Build a project with a laravel and react, change the view to show a react component.
• open the preview browser
• page is blank and error in the dev tools console

Expected behavior

Laravel/React projects should behave the same on all servers

Describe the bug

Any ruby gems installed when the workspace is initialized do not persist when the workspace is stoped and restarted.

Steps to reproduce

1. Ensure that install value is set to 1 in the github-changelog-generator section of starter.ini
2. Create a fresh workspace from this repo or a brach or fork of this repo.
3. Verify that the github_changelog_generator gem is installed
   • run the command gem query --local | grep github_changelog_generator
     • You will see output something like: github_changelog_generator (1.15.2)
4. Stop and workspace
5. Start the workspace
6. Verify that the github_changelog_generator gem is installed
   • run the command gem query --local | grep github_changelog_generator
   • You will not see any output

Furthermore after restarting the workspace and runningrake changelog you will see the following error:

rake aborted!
LoadError: cannot load such file -- github_changelog_generator/task

Expected behavior

All ruby gems installed during workspace initialization should persist across workspace restarts

Additional information

See here.
There are many gems installed internall by gitpod that are also blown away on workspace restart.
Location of installed gems: ls -al /home/gitpod/.rvm/gems/ruby-2.6.6/gems

Describe the bug

Any aliases written to .bashrc or .bash_profile will only work out of the box from the Init terminal, other currrently open terminals (not new ones though) will not have those aliases or functions until a new terminal (in the case of .bashrc) or .bash_profile is sourced.

Screenshots

Steps to reproduce

1. Create a new repo from the workspace
2. run debug-on in an currently open terminal that is not the Init terminal/

Expected behavior

Any terminal should have all the aliases and functions available that were written in during the gitpod initialization.

Additional information

Eventually this system will need to be refactored to use $HOME/.bashrc.d so that .bashrc does not become too bloated.

Problem this feature will solve

README is out of date with no table of contents and needs formatting.

Proposed Solution

Update, reformat and add a table of contents to the README

Problem this feature will solve

A spinner is not informative enough for operations such as rsync that can take a long time.

Background

Long lasting processes should be as informative as possible.
https://github.com/Xfennec/progress

Proposed Solution

Install progress - Coreutils Progress Viewer

Constraints and Assumptions

progress works for the following core util processes:

cp, mv, dd, tar, cat, rsync, grep, fgrep, egrep, cut, sort, md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, adb, gzip, gunzip, bzip2, bunzip2, xz, unxz, lzma, unlzma, 7z, 7za, zcat, bzcat, lzcat, split, gpg

Alternatives or Workarounds

Additional context

This feature will be implemented where the project scaffolding is copied over to the project workspace using rsync.

Problem this feature will solve

phpmyadmin it won't work out of the box with the PHP development server server from /public and it is not as robust as Apache 2.

Background

Currently the PHP development server is used by default in the Gitpod environment. The PHP development server is much more limited than Apache which is already setup in the gitpod environment.

Proposed Solution

Make Apache the default web server

Constraints and Assumptions

Alternatives or Workarounds

Additional context

Add any other context or screenshots about the feature request here.

Describe the bug

log calls made with a string that starts with --> outputs an error in the console.

Screenshots

Steps to reproduce

Make a log call with a string that starts with -->
Error:
line 130: printf: --: invalid option

Expected behavior

log functions should be able to handle any string

Additional information

Describe the bug

restarting a workspaces gives an intermittent error when opening the preview:

2021/02/03 16:16:18 error while issuing request: Post "http://localhost:23000/gitpod/cli": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
2021/02/03 16:16:53 error while issuing request: Post "http://localhost:23000/gitpod/cli": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Screenshots

Steps to reproduce

1. create a new workspace
2. stop the workspace
3. restart the workspace

Expected behavior

There should be no errors

Additional information

Looks like the preview browser is trying to open again when its already open.

Describe the bug

Sometimes this error pops up

DocumentRoot '/workspace/gitpod-laravel8-starter/public' is not a directory, or is not readable
Action 'start' failed.
The Apache error log may have more information

However after the system is ready Apache will start manually via start_apache

Screenshots

Steps to reproduce

Happens every time right now in https://github.com/apolopena/gitpod-laravel8-starter
Doesn't seem tot happen at all in https://github.com/apolopena/laravel8-starter-b892185

Update:
Does not happen everytime in https://github.com/apolopena/gitpod-laravel8-starter either

Expected behavior

Apache should start at any time during the init command.

Additional information

This could be related to gitpod-io/workspace-images#354
I will dive deeper on this and provide an update
It is odd that the issue is replicable in one repo but not in another when the code in the two repos is virtually the same.

Update:
This did not have to do with gitpod-io/workspace-images/pull/354. Rather it seems like osmetime the cpu in the cloud just lags and the public folder was not available at the time the server was told to start.

The MySql Daemon has a long initialization time and, that process is asynchronous and blocks whatever terminal it hijacks. This results in a two fold issue:

1. The timing of init and command tasks in .gitpod.yml becomes inconsistant.
2. The long wait time without a user message is a bad user experience as the workspace appears to be broken since some tasks freeze and other run out of sync due to the asynchronous blocking nature of mysqld.

*All of this can mostly be fixed by waiting for the MySql port (3306) to be open and notifying the user accordingly.

Fixes required:

1. • Add a MySql initialization message with a spinner and display it wherever the user can see it (i.e not in a tab an unfocused tab). This message should only display when MySql is initializing which will be on the first run of the workspace only.
2. • Refactor the .gitpod.yml tasks to account for mysqld initialization throwing off the order of when tasks run

Describe the bug

composer libraries in /public/phpmyadmin/vendor are bloating the phpmyadmin optional install
Branch: development

Screenshots

Steps to reproduce

1. Build a Gitpod workspace with INSTALL_PHPMAYADMIN=1 in starter.ini
2. Go to the dash board and look at that workspace. There will be around 9663

Expected behavior

Should probably be less than a couple hundred files overall for just Laravel and phpmyadmin installs.

Additional information

Probably just need to dynamically add /vendor/public/phpmyadmin to /.gitignore