gitlab-runner exec shell job_namegdk start
( gdk doctorbin/rake frontend:fixturesyarn karmayarn jestCHROME_HEADLESS=0 bundle exec rspec spec/features/projects/tree/create_directory_spec.rbscreenshot_and_save_pagescreenshot_and_open_imagelive_debugscripts/static-analysis (long)yarn eslint (faster)fdescribe and fit for focused karma specsSee https://gitlab.com/gitlab-org/gitlab/tree/master/qa#how-can-i-use-it for more details.
cd qabundlebrew cask <install|reinstall> chromedriverbundle exec bin/qa Test::Instance::All http://0.0.0.0:3000 -- qa/specs/features/ee/browser_ui/1_manage/project/project_templates_spec.rbTo run the QA specs in RubyMine, use a custom rspec runner configuration (right click on the arrow next to the example in the gutter), and set the qa/bin/rubymine script as the custom RSpec runner script, and the working directory as qa.
See more detailed instructions for this process here: https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/end_to_end_test_configuration.md#starting-tests-using-the-rubymine-gutter
cd sites/handbook && NO_CONTRACTS=true bundle exec middleman/admin/licenseputs or p will ONLY show up in gdk tail railslogger.info('...') will ONLY show up in tail -f log/development.logMOVED: Ths section on debugging the GDK with the RubyMine debugger has been moved to https://handbook.gitlab.com/handbook/tools-and-tips/editors-and-ides/jetbrains-ides/individual-ides/rubymine/#debugging
git rebase -i master) and message cleanup via reword/fixup are worth learning more about if you are unfamiliar with them.merge-base (the common ancestor of your branch HEAD and the upstream branch master) from the possibility of "conflict resolution" when rebasing against the latest upstream master.git rebase -i $(git merge-base HEAD master). This lets you do your interactive rebase against the merge-base without any chance of having to deal with conflicts at the same time. Make sure that the merge-base commit is contained on your master branch (i.e. you didn't just fetch and checkout the branch directly without updating master). You could just git fetch then rebase against origin/master, but this negates the benefit of using --force-with-lease.git push --force-with-lease (Or just wait until after the next step to push if you don't want to trigger an extra unnecessary build)git rebase master, to rebase against the latest master, and resolve any conflicts against your cleaned-up, interactively-rebased branch.git push --force-with-lease (force-with-lease ensures nobody else has pushed to the branch since you last pulled)When a branch has followed a merge instead of a rebase workflow, it can get very confusing to know what is going on, and you want to just squash it down to a single commit. But, you can't just do a regular interactive rebase relative to master if the branch has had master merged into it. Here's what you have to do instead.
Note there may be more efficient ways of doing this, suggestions are welcome. Also note that sometimes this doesn't work, you'll end up with almost all the changes from the branch uncommitted after step 5 - not sure why :(
Assuming branch is named branch and upstream is named master:
git log master..branch --oneline123456.abcdef.git reset --hard abcdefmerge --squash the last commit: git merge --squash 123456git restore --staged .git checkout .git clean -dfThough the contributor and development docs are the single source of truth, there are some additional habits that may be worth developing when you're new to the code contribution process.
Depending on your existing habits and git practices the habits below may help mitigate pain during code submissions.
About testing:
Some frontendmasters workshops related to testing that I want to take after the web security workshop:
MOVED: There is now a dedicated handbook section on JetBrains IDEs: https://handbook.gitlab.com/handbook/tools-and-tips/editors-and-ides/jetbrains-ides/