Fedora QA Landingpage

Fedora QA info aggregator

Setup

Clone this repository and in the cloned directory run:

$ yarn install
$ yarn start

The landingpage is now running at http://localhost:3000

Tips for contributors to this project participating in Outreachy or Google summer of code

• Get familiar with Fedora QA, see our join guide.

• Get involved, participate in release validation testing or updates teting. If there is a testday, participate in it as well. By doing this, you will get a better picture of what Fedora QA community does.

• Read the document describing motivation behind Fedora QA Dashboard

• Read the UX feedback

• Try Fedora QA Dashboard yourself, clone the repo, browse the code, try to do a small change and see the results. If you want to start contributing to this project, look for issues tagged "easyfix".

How to generate your public SSH Key, because you will need it before you can do a pull request

• Before generating your key, you should check to make sure you dont already have your ssh key

• You can easily check to see if you already have the key by going to the directory and listing it

  $ cd ~/.ssh $ ls authorized_keys2 id_dsa known_hosts config id_dsa.pub

• Open your shell/terminal and type in the command

  $ ssh-keygen -o

• Visit (https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key) for more information on SSH Keys.

How to do pull requests

• create an account on Pagure, don't forget to add your public ssh key to Pagure (click on your avatar > My settings > SSH Keys > Add SSH key)

• fork this repository (upper right corner)

• clone your forked repo using SSH option by running the command below

$ git clone <SSH link you copied from the upper right corner of your forked repo>

• add our repo as upstream remote by running the command below

$ git remote add upstream https://pagure.io/fedora-qa/landingpage.git

• to get the latest commit from our branch do (you'll need this later):

$ git checkout master
$ git fetch upstream/master
$ git rebase upstream/master

• it is a good practise to create separate branch for each feature or fix you are going to do:

$ git checkout -b <name of new branch>

• once you are done coding, commit your changes and push them, use git diff and git status to see if you haven't changed anything else by accident; the first time you push your branch to origin use this command:

$ git push -u origin <branch name>

• create pull request, provide description or at least link to an issue.

• you will probably add several more commits after the feedback from pull request review, in the end squash those commits to one, you will need a hash of a commit that is before the commits you want to squash :

$ git log
commit <hash>
  your change 3

commit <hash>
  your change 2

commit <hash>
  your change 1

commit <hash>
  you want to use hash of this commit


$ git rebase -i <the commit before the ones you want to squash>

• if you squashed commits, you'll have to do force push:

$ git push -f

• it is possible that there have been changes in our master meanwhile, or you simply forgot to fetch changes before you started, you'll have to fetch new changes (see above), checkout to your branch and rebase your branch:

$ git rebase master

• when rebasing, there might be conflicts you'll have to resolve