From 33b290dc9e665148978909959f6161cfbedec526 Mon Sep 17 00:00:00 2001 From: Cassie Tarakajian Date: Mon, 1 Jun 2020 15:31:59 -0400 Subject: [PATCH 1/3] RE: #1421, Add documentation about creating a GitHub release after creating a tag --- developer_docs/release.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/developer_docs/release.md b/developer_docs/release.md index 87ced793..302c8019 100644 --- a/developer_docs/release.md +++ b/developer_docs/release.md @@ -19,6 +19,13 @@ This project release guide is based on 7. `$ git push && git push --tags` 8. `$ git checkout develop` 9. `$ git merge --no-ff release-` +10. Create a release on GitHub. You can do this in one of two ways: + 1. (Preferred) Use the [`hub` command line tool](https://hub.github.com/). You can automate adding all commit messages since the last release with the following command: + ```sh + $ hub release create -d -m "" -m "$(git log `git describe --tags --abbrev=0 HEAD^`..HEAD --oneline)" ` + ``` + Note that this creates a draft release, which you can then edit on GitHub. This allows you to create release notes from the list of commit messages, but then edit these notes as you wish. + 2. [Draft a new release on Github](https://github.com/processing/p5.js-web-editor/releases/new). Travis CI will automatically deploy the release to production, as well as push a production tagged Docker image to DockerHub. From 01816d266276e29d3a92d491a99586d410035ce4 Mon Sep 17 00:00:00 2001 From: Cassie Tarakajian Date: Mon, 1 Jun 2020 16:30:14 -0400 Subject: [PATCH 2/3] [#1421] Update git commit guide Modify the git commit guide to be clearer, specifically asking to link GitHub issues with every commit. Also update the pull request template with the line "Fixes #issue-number" so that every PR will close an issue when it is merged. --- .github/PULL_REQUEST_TEMPLATE.md | 2 ++ developer_docs/development.md | 37 ++++++++++++++++++-------------- 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index cbe15e3f..95cb6f48 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,3 +1,5 @@ +Fixes #issue-number + I have verified that this pull request: * [ ] has no linting errors (`npm run lint`) diff --git a/developer_docs/development.md b/developer_docs/development.md index 23780c6d..361830c3 100644 --- a/developer_docs/development.md +++ b/developer_docs/development.md @@ -6,8 +6,9 @@ A guide for adding code to this project. - [Installation](#installation) - [Development Workflow](#development-workflow) - [Tests](#tests) - - [Writing Git Commit Messages](#writing-git-commit-messages) - - [Tips](#tips) + - [Committing Code](#committing-code) + - [General Rules](#general-rules) + - [Commit Messages](#commit-messages) - [Design](#design) - [Technologies Used](#technologies-used) @@ -31,7 +32,8 @@ To run the test suite simply run `npm test` (after installing dependencies with A sample unit test could be found here: [Nav.test.jsx](../client/components/__test__/Nav.test.jsx). -## Writing Git Commit Messages +## Committing Code +Inspired by [Git/GitHub commit standards & conventions](https://gist.github.com/digitaljhelms/3761873). Good commit messages serve at least three important purposes: @@ -39,33 +41,36 @@ Good commit messages serve at least three important purposes: * They help us write good release notes. * They help future maintainers understand your change and the reasons behind it. + +### General Rules +* Make [atomic commits](http://en.wikipedia.org/wiki/Atomic_commit) of changes, even across multiple files, in logical units. That is, as much as possible, each commit should be focused on one specific purpose. +* As much as possible, make sure a commit does not contain unnecessary whitespace changes. This can be checked as follows: + +``` +$ git diff --check +``` + +### Commit Messages + Structure your commit message like this: ``` - Short (50 chars or less) summary of changes ( involving Fixes #Issue-number keyword ) + [#issueid] Short (50 chars or less) summary of changes - More detailed explanatory text, if necessary. Wrap it to about 72 - characters or so. In some contexts, the first line is treated as the - subject of an email and the rest of the text as the body. The blank - line separating the summary from the body is critical (unless you omit - the body entirely); tools like rebase can get confused if you run the - two together. + More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - - Typically a hyphen or asterisk is used for the bullet, preceded by a - single space, with blank lines in between, but conventions vary here + - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here ``` - * Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed". +* Link the GitHub issue you are working on in the summary line in brackets, e.g. [#123] * Always leave the second line blank. * Be as descriptive as possible in the description. It helps reasoning about the intention of commits and gives more context about why changes happened. - -### Tips - * If it seems difficult to summarize what your commit does, it may be because it includes several logical changes or bug fixes, and are better split up into several commits using `git add -p`. +* Note that you can connect multiple issues to a commit, if necessary: `[#123][#456] Add Button component` ## Design - [Style Guide/Design System on Figma](https://github.com/processing/p5.js-web-editor/labels/good%20medium%20issues) From 350284402939de951cebf7f576197b7e7532b43f Mon Sep 17 00:00:00 2001 From: Andrew Nicolaou Date: Mon, 8 Jun 2020 10:50:58 +0200 Subject: [PATCH 3/3] Fix issue with fullscreen not appearing (#1451) --- client/modules/IDE/pages/FullView.jsx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/client/modules/IDE/pages/FullView.jsx b/client/modules/IDE/pages/FullView.jsx index cbdc89d6..f8f9e96f 100644 --- a/client/modules/IDE/pages/FullView.jsx +++ b/client/modules/IDE/pages/FullView.jsx @@ -10,7 +10,7 @@ import * as ProjectActions from '../actions/project'; class FullView extends React.Component { componentDidMount() { - this.props.getProject(this.props.params.project_id); + this.props.getProject(this.props.params.project_id, this.props.params.username); } ident = () => {} @@ -56,7 +56,8 @@ class FullView extends React.Component { FullView.propTypes = { params: PropTypes.shape({ - project_id: PropTypes.string + project_id: PropTypes.string, + username: PropTypes.string }).isRequired, project: PropTypes.shape({ name: PropTypes.string,