/open-source

Information and Guides for Infinite Red Open Source Projects

Infinite Red Open Source Dashboard

Hey there! Welcome!

This repo contains markdown files with info and guides for Infinite Red's open source libraries and tooling.

We're glad you're here and feel free to poke around. If you notice an issue, feel free to submit a PR. You can easily edit Markdown files right in Github by clicking the little 📝 icon on the top right.

Infinite Red Websites

infinite.red

Infinite Red Open Source Projects

This list is currently being fleshed out. There are several missing projects and the status / CI / CD is not fully validated. We'll be working on this as we have time.

Name Status CI CD Build Version
Ignite CLI Active CircleCI version
Ignite Bowser Maintenance CircleCI version
Reactotron Active CircleCI version
Reactotron Core Client Active CircleCI version
Reactotron Core Server Active CircleCI version
Reactotron React Native Active CircleCI version
Reactotron React JS Active CircleCI version
Reactotron MST Active CircleCI version
Reactotron Apisauce Active CircleCI version
Reactotron Redux Active CircleCI version
Reactotron Redux Saga Active CircleCI version
Gluegun Active CircleCI version
Solidarity Active version
Solidarity React Native Active CircleCI version
apisauce Maintenance CircleCI version
Ramdasauce Maintenance CircleCI version

Legend: ✅ = Setup, ❌ = Not setup, 🚧 = Currently under construction, ❓ = Unknown status, ❎ = Not applicable

Guide to squash commits

Guide to squash messages for auto deployment

Each of these keywords must be followed by a colon. They can also be followed by a parenthetical which will add that parenthetical word in bold in front of the message in the changelog. E.g. fix: Updated gluegun or fix(deps): Updated gluegun are both valid.

Skip CI: [skip ci]

This will not run the deployment script. I usually put it in the body of the commit message, not the title (first line).

I use this a lot to "group" multiple fixes in one release. So I might merge 3 PRs, have the first 2 have [skip ci], and the third I let the CI run, so it gathers up all 3 changes into one changelog and releases once.

Non-release changes

**Code base maintenance: chore: Message Documentation: docs: Message

These will not add to the changelog nor (by itself) trigger a release. However, be aware that if there are previous [skip ci] changes, you will trigger a release with all of the unreleased fix or feat changes. This is sometimes useful if you merge a ton of PRs with [skip ci] and want to trigger a release: just do an empty commit like so:

git commit --allow-empty -m "chore(ci): Trigger release"

... and push directly to master.

Patch-level release: fix: Message

This will add to the "Bugfixes" section of the changelog and trigger a release (unless [skip ci]).

Minor version release: feat: Message

This will add to the "Features" section of the changelog and trigger a release (unless [skip ci]).

Major version release:

In your commit message body (not title), whether it's fix or feat, include the following:

BREAKING CHANGE: Describe the breaking change here

So an example:

breaking change example

Gotchas

  1. Don't trigger more than one release at a time. One or both will fail.
  2. Do not put BREAKING CHANGES:, it doesn't work. :sadpanda: Only BREAKING CHANGE: (with the colon). And it must be in the commit message body, not the title.
  3. I've never released a major version without some sort of hiccup. Maybe next time?

Infinite Red Guides