RadioNope Development
A group of friends who love music and are happy to share it with the masses.
A typical update involves adding a show and a DJ. We'll need some but not all of the following info:
-
Show title
-
Show podcast directory or URL
-
Show image
-
Show tags
-
Show tagline
-
Show description
-
Show social media
-
Show day/timeslot
-
Show re-airs if any
-
DJ name
-
DJ blurb/bio
-
DJ social media
-
DJ image
Adding a band/DJ requires the following steps:
- Add show markdown file to
/_shows
- Add show image to
/images/shows
- Add DJ markdown file to
/_people
- Add DJ image to
/images/people
- Update schedule:
/data/schedule/${dayname}.md
- Once verified and changes merged in, run Archive & Deploy (below)
See the corresponding sh
files in root.
- Archive should be already copied to server root.
- Run archive before a deploy, which backs up radionope.com on the server, excluding podcasts directory:
- ssh into server
- run archive script:
sh archive.sh
- verify that a zip file has been added to
/archives
directory with timestamp
Then:
- make sure your
_site
directory has been built with the latest code you that want to deploy by runningbundle exec jekyll build
- run deploy.sh from the root of your local repo:
sh deploy.sh
- verify site changes online
Great! Do you know Jekyll? Do you know Jekyll on Github Pages? If not, continue reading...
If you don't already have Jekyll, run: gem install jekyll
If you don't already have Bundler, run: gem install bundler
If you don't already have the site locally, fork and clone.
To get dependencies run from the site directory: bundle install
serve only
bundle exec jekyll serve
serve and watch for changes
bundle exec jekyll serve --watch
serve drafts and watch for changes
bundle exec jekyll serve --watch --drafts
hub checkout https://github.com/org/repo/pulls/1234
- fork; clone; branch
- write;
- commit post; pull request; merge
- If you are not already in the authors file, add yourself
- In a local fork, preferably in a branch off of master, write in a markdown file (
.md
) with at least the minimal meta information at the top of the document
* optional: a_drafts
folder is available if you'd like
* optional: commit the work to manage "revisions"; push to your remote to keep your work "backed up" - When ready for review (final or incremental), push the post upstream and open a pull request
* note: if you are looking for comments but not ready to publish, keep the post in the_drafts
directory; if you are ready to publish, move the file to the_posts
directory and prefix the filename with the date (2015-09-27-my-fence-post.md
) before opening the pull request - Colleagues can then view and comment on the post (potentially with a "diff" of a previous version, if one exists in the "upstream")
- Once you and the reviewer(s) are satisfied, merge the PR. If the content was moved to the
_posts
directory in the PR, then you are now "published."