gitlab-runner exec shell job_name
CHROME_HEADLESS=0 bundle exec rspec spec/features/projects/tree/create_directory_spec.rb
fitfor focused karma specs
See https://gitlab.com/gitlab-org/gitlab/tree/master/qa#how-can-i-use-it for more details.
brew cask <install|reinstall> chromedriver
bundle exec bin/qa Test::Instance::All http://0.0.0.0:3000 -- qa/specs/features/ee/browser_ui/1_manage/project/project_templates_spec.rb
To 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
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
pwill ONLY show up in
gdk tail rails
logger.info('...')will ONLY show up in
tail -f log/development.log
MOVED: 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
fixupare worth learning more about if you are unfamiliar with them.
merge-base(the common ancestor of your branch
HEADand the upstream branch
master) from the possibility of "conflict resolution" when rebasing against the latest upstream
git rebase -i $(git merge-base HEAD master). This lets you do your interactive rebase against the
merge-basewithout any chance of having to deal with conflicts at the same time. Make sure that the
merge-basecommit 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 fetchthen rebase against
origin/master, but this negates the benefit of using
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
git log master..branch --oneline
git reset --hard abcdef
merge --squashthe last commit:
git merge --squash 123456
git restore --staged .
git checkout .
git clean -df
Though 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.
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/