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
/archivesdirectory with timestamp
Then:
- make sure your
_sitedirectory 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_draftsfolder 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_draftsdirectory; if you are ready to publish, move the file to the_postsdirectory 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
_postsdirectory in the PR, then you are now "published."