Giter VIP home page Giter VIP logo

supermarket's Introduction

Supermarket

unit lint ctl-cookbook-testing Inline docs

Supermarket is Chef's community repository for cookbooks, currently hosted at supermarket.chef.io. Supermarket can also run internally, behind-the-firewall.

Umbrella Project: Supermarket

The code is designed to be easy for others to contribute. The goal of the README file is to familiarize you with the project. You can find detailed information about Supermarket at Wiki page.

If you want to contribute to Supermarket, read the contributor's workflow for license information and other helpful tips that aid you in getting started. There are project artifacts such as planning docs, wireframes, recorded demos, and team retrospectives at public Google Drive folder.

If you have questions, feature ideas, or other suggestions, please open a GitHub Issue.

This repository has the code for the Supermarket application and the omnibus definition used to build the deb/rpm packages. Other Supermarket related repositories are:

Development

Configuration

Configure the dotenv keys and secrets. See .env.example for required keys and secrets. docs/CONFIGURING.md page details the not-so-straightforward configuration information required to setup Supermarket working locally.

Local Environment

These instructions are tested and verified on macOS Catalina (10.15).

Dependency Services

As Docker Containers
  1. Install docker

    brew cask install docker

Ensure you have a PostgreSQL version installed on the local filesystem for development libraries to be available for building the pg gem. See the instructions for locally running PostgreSQL below, however omit the steps where the service is running.

  1. Start the docker containers.

    cd src/supermarket
    docker-compose up
As Locally Running Processes
  1. Install Postgres by following any of the below instructions:

    • Install the Postgres App:

      This is probably the simplest way to get Postgres running on your mac. You can then start a Postgres server through the GUI of the app. If you go this route, then you'll have to add /Applications/Postgres.app/Contents/Versions/9.4/bin/ or the equivalent path to obtain the pg gem to build.

    • Through Homebrew:

      brew install postgresql

    When installed through homebrew, Postgres often requires additional configuration, see this blog post for instructions. Ensure to start the Postgresql server by following the command given below.

    pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
  2. Install Redis. You can install it with Homebrew. Follow the instructions in the install output to start the redis server.

    brew install redis

    Run the redis server using command:

    redis-server --daemonize yes

Development Environment

  1. Ensure you have Xcode installed.

  2. Install a Ruby manager. If you don't already have one, you will need a Ruby manager to install the appropriate Ruby release, such as:

    • RVM
    • Rbenv
    • chruby
    • or any other Ruby version manager that may come along.
  3. Use your ruby manager to install the necessary Ruby release. For instructions on this, please see the manager's documentation.

  4. Ensure you have the Supermarket repo cloned to your machine. If not, clone it.

  5. Navigate to that directory.

    cd <supermarket-repo>
  6. Again, navigate to the src folder.

    cd src/supermarket
  7. Install Bundler gem.

    gem install bundler:2.1.4 --user-install
  8. Install required gems:

    bundle install

    Note: You might encounter the following errors. The possible fixes are also provided here.

  9. Create the database, migrate to it, and then seed the database:

    bundle exec rails db:setup
  10. Add required Postgres extensions.

    psql supermarket_development -c 'create extension plpgsql'
    psql supermarket_development -c 'create extension pg_trgm'

    Note: Ignore if the above 2 commands displays the following error: extension already exists.

  11. Start the server:

    bundle exec foreman start

    Note: If you receive errors, ensure that redis and Postgres are running.

Setting up Auth

Supermarket uses oc-id running on a Chef Infra Server to authenticate users to Supermarket.

IF YOU ARE AN INTERNAL CHEF STAFFER - We will be performing some settings prior to set you up with oc-id. Consult the internal wiki on setting up your Supermarket dev environment (or ask a friendly team member!).

Note: Authentication currently requires a live Chef Infra Server running oc-id. We are working on a solution that would allow a developer to run the authentication locally. Stay tuned.

Create a new application and register it on oc-id (I called my application Application:Supermarket Development). Set the callback URL to http://localhost:3000/auth/chef_oauth2/callback or whatever localhost domain you use.

In your local copy of the Supermarket repo, copy the .env file to .env.development. Open up .env.development and replace these values:

CHEF_OAUTH2_APP_ID=YOUR_CHEF_OAUTH2_APP_ID
CHEF_OAUTH2_SECRET=YOUR_CHEF_OAUTH2_SECRET

with these values:

CHEF_OAUTH2_APP_ID=[Application ID of the oc-id application you just registered]
CHEF_OAUTH2_SECRET=[Secret of the oc-id application you just registered]

Restart your foreman server.

Now, when you click Sign In, you will be taken to your supermarket account with your Chef account!

Note: If you receive an omniauth csrf detected error, try clearing your browser's cache.

SPDX license linking for cookbooks

If a cookbook that has licenseId, which is also mentioned in SPDX license listed at https://github.com/spdx/license-list-data/blob/master/json/licenses.json, you need to update with respective license URL.

When a new cookbook is uploaded, license url information is fetched from the above link and is updated.

For an existing implementation of supermarket, there is a provision running with some ctl commands, for updating the information for cookbooks already there in system.

Following commands are available to update the license URLs for cookbooks:

Update licenses URLs for all the cookbooks in the system

spdx-all

Update for a single cookbook

spdx-latest <cookbook_name>

Update for a particular version of a cookbook

spdx-on-version <cookbook_name> <cookbook_version>

Connecting your GitHub Account

There are a couple of features that depend on GitHub integration (some quality metrics in Fieri) with your development environment. Follow these steps to create an application with your Github account:

  1. Log into your Github account.
  2. Click on your username in the upper right-hand corner. Your Profile page appears.
  3. Click the Edit Profile button in the upper right corner of the Profile page.
  4. Click Applications from the vertical menu on the left-hand side.
  5. Click the Register new Application button from the section labeled Developer applications at the top of the screen.
  6. Specify the name of your application (For example, Chef-Supermarket-Testing), then set the homepage URL as http://localhost:3000 (or whatever localhost domain that you use).
  7. Set the Authorization callback URL to http://localhost:3000 (or your localhost domain of choice).
  8. Click the Register application button.
  9. Open the .env.development file in your local copy of the Supermarket repo.
  10. Replace these values:
GITHUB_KEY=YOUR_GITHUB_KEY
GITHUB_SECRET=YOUR_GITHUB_SECRET

with:

GITHUB_KEY=[Your new application's client ID]
GITHUB_SECRET=[Your new application's client secret]
  1. Next, create a Github Access token. You can also do this from the Applications section of your Profile page.

  2. Navigate to the Personal access tokens section.

  3. Click the Generate new token button.

  4. When prompted, enter your Github password.

  5. Enter the Token description. For example, testing-supermarket.

  6. Leave the scopes at the defaults.

  7. Click the Generate token button.

  8. Copy the token generated and secure it safe!.

  9. Open up your .env.development file again.

  10. Replace this value:

GITHUB_ACCESS_TOKEN=YOUR_GITHUB_ACCESS_TOKEN

with:

GITHUB_ACCESS_TOKEN=[Token you just generated through Github]

Connecting your GitHub Enterprise Account

There are a couple of features that depend on GitHub Enterprise integration (some quality metrics in Fieri) with your development environment. Follow these steps to create an application with your Github account::

  1. Log into your Github Enterprise account.
  2. Click on your username in the upper right-hand corner.
  3. Click User settings in the vertical menu on the right corner. Your public Profile page appears.
  4. Click Developer settings in the vertical menu on the left-hand side.
  5. Click the section labeled Developer settings with text OAuth App at the top of the screen.
  6. Click new OAuth App. You can now register to a new OAuth application page.
  7. Specify the name of your application. (For example, testing-supermarket-app), then set the homepage URL as http://localhost:3000 (or whatever localhost domain that you use).
  8. Set the Authorization callback URL to http://localhost:3000/auth/github/callback (or your localhost domain of choice).
  9. Click the **"Register application button.
  10. Open up the .env.development file in your local copy of the Supermarket repo.
  11. Replace these values:
GITHUB_KEY=YOUR_GITHUB_KEY
GITHUB_SECRET=YOUR_GITHUB_SECRET
GITHUB_ENTERPRISE_URL=YOUR_GITHUB_ENTERPRISE_URL
GITHUB_CLIENT_OPTION_SITE=YOUR_GITHUB_ENTERPRISE_SITE
GITHUB_CLIENT_OPTION_AUTHORIZE_URL=YOUR_GITHUB_ENTERPRISE_AUTHORIZE_URL
GITHUB_CLIENT_OPTION_ACCESS_TOKEN_URL=YOUR_GITHUB_ENTERPRISE_ACCESS_TOKEN_URL

with:

GITHUB_KEY=[Your new application's client ID]
GITHUB_SECRET=[Your new application's client secret]
GITHUB_ENTERPRISE_URL=[Your GitHub Enterprise URL]
GITHUB_CLIENT_OPTION_SITE=YOURGITHUBENTERPRISEURL/api/v3
GITHUB_CLIENT_OPTION_AUTHORIZE_URL=YOURGITHUBENTERPRISEURL/login/oauth/authorize
GITHUB_CLIENT_OPTION_ACCESS_TOKEN_URL=YOURGITHUBENTERPRISEURL/login/oauth/access_token
  1. Next, create a GitHub Access token. You also do this from the Developer settings section.

  2. Click Personal access tokens. The Personal access tokens page appears.

  3. Navigate to the Personal access tokens section.

  4. Click the Generate new token button.

  5. When prompted, enter your GitHub password.

  6. Enter the Token description. For example, testing-supermarket.

  7. Leave the scopes at the defaults.

  8. Click the Generate token button.

  9. Copy the token generated and secure it safe!.

  10. Open up your .env.development file again.

  11. Replace this value:

GITHUB_ACCESS_TOKEN=YOUR_GITHUB_ACCESS_TOKEN

with:

GITHUB_ACCESS_TOKEN=[Token you just generated through Github]

Tests

Requirements for tests: PhantomJS 1.8, Node.

Run the entire test suite (rspec, rubocop and mocha) with:

bundle exec rake spec:all

Acceptance Tests

Acceptance tests are run with Capybara. Run rake spec:features to run the specs in spec/features. The default rake spec also runs these.

When writing feature specs, the Rack::Test driver is used by default. If the Poltergeist driver is required to be used (for example, an acceptance test that uses AJAX), add the use_poltergeist: true metadata to the spec.

Some specs run using PhantomJS, which must be installed for the test suite to pass.

JavaScript Tests

The JavaScript specs are run with Karma and use the Mocha test framework and the Chai Assertion Library.

The specs live in spec/javascripts. Run rake spec:javascripts to run the specs, and rake spec:javascripts:watch to run them continuously and watch for changes.

Node.js is required to run the JavaScript tests.

Background Jobs

Read about Supermarket's background jobs in the wiki.

Feature Flags

Supermarket uses a .env file to configure itself. Inside this file are key/value pairs. These key/value pairs will be exported as environment variables when the app runs, and Supermarket looks for these keys as environment variables when it needs to read a value that's configurable.

One of these keys is called FEATURES and it controls a number of features that can be turned on and off. Here are the available features that can be toggled:

  • tools
  • fieri
  • announcement
  • github
  • no_crawl

supermarket's People

Contributors

antima-gupta avatar bcobb avatar brettchalupa avatar chef-ci avatar chef-delivery avatar cwebberops avatar dependabot-preview[bot] avatar dependabot[bot] avatar dheerajd-msys avatar ianmadd avatar jeremiahsnapp avatar kirtfitzpatrick avatar lamont-granquist avatar loganmeetsworld avatar manick-vel-11 avatar msys-sgarg avatar nellshamrell avatar okappati avatar pratixha avatar rajeshpaul38 avatar raskchanky avatar robbkidd avatar saghoshprogress avatar schisamo avatar sethvargo avatar smith avatar tas50 avatar tduffield avatar tristanoneil avatar tuahk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

supermarket's Issues

Use rails_config for settings

Right now we're using a combination of environment variables and magiconf for app configuration. Environment variables are very nice if you're running on something like Heroku, but it feels like the combination of these two methods causes more complexity than is needed.

I've been using rails_config on some projects recently and it's been near-perfect. Here's why:

  • Set your defaults in config/settings.yml. This file is checked in and always present, so Settings.some.deep.thing.defined.there will never blow up with a nillybopper and you can just have people run the app in dev mode without having to do any initial configuration.
  • If you want to override something locally, just create a (.gitignored) config/settings.local.yml and it gets merged with the other settings.
  • When you deploy you can pretty much just do file "#{release_path}/config/settings/production.yml" { content data_bag_item('myapp').to_yaml } (or node['myapp].to_yaml if using attributes instead of data bags) and you're done.
  • When you're testing you can just do Settings.stub_chain(:some, :deep, :thing).and_return('something').

I don't have a PR implementing this but would strongly recommend using it.

CLA Signing

These are somethings we'll need to flush out in order to most effectively build out the CLA signing process.

  1. Is there a need to view a CLA once it's been signed? What does that look like?
  2. Currently there can be multiple versions of a ICLA/CCLA that is tied to a signature. Do we want to support that?
  3. From the CCLA contributors view, what happens when you click on an organization?
  4. Related to the previous item does an organization serve any other purpose in the app other than collecting required information for a CCLA signature to be valid?
  5. If the user updates their CLA contact information is their signature still valid? Or do they need to "resign"?

Front-End Design

Here's what I was thinking for the UI/design:

cla

A couple things to point out:

  1. The header is cargo-culted from the existing community site. We can deal with that in a separate issue.
  2. The links on the left are probably to static (or semi-static) pages with helpful information that currently exists on the wiki.
  3. The font is the "official" Opscode Gotham font.
  4. The GitHub/JIRA/whatever fields below the line will be optional (for now)

Here's the raw AI file if you have Illustrator and want to make some suggestions/improvements: http://cl.ly/2L0W0M1w1B0k

/cc @jamesc @cnunciato @smith @nathenharvey any feedback?

How can we better organize cookbooks in like-kind collections?

We've gotten a lot of feedback from the community thus far that categories are not very useful for helping drill down to find meaningful cookbooks. A tag system is nice, but it goes too far in the other direction and you end up with a bunch of duplicate tags or not useful tags as cookbook meta data.

@sethvargo specifically brought up the downsides of using categories and how some cookbooks that get thrown into the "other" category could get lost in the nebulous. I've had lots of internal conflict around this because we want to provide structure for organization, but it can't be so rigid that things get put in categories that are not reflective of what they actually are designed for. Conversely, a tagging system feels too open and structureless.

Outcomes of this discussion:

  1. What value does adding structure to cookbook searching through categories or tags really provide?
  2. When would it be used and when it not be used?
  3. How we can get the right level of structure in place such that it's a more natural organization based on tangible data points within the cookbook itself without being too rigid or too loosely defined?

Namespacing

Ping @nathenharvey (hoping to keep things on here since more people have github accounts than are on the new ML, please let me know if you would rather move it).

Okay, so what do I mean by namespacing? The short version is separating the name of the cookbook from the name of its record on the community site (nee. package server). Right now we enforce that these two things must be the same, which presents a serious barrier to entry with sharing cookbooks when combined with the (IMO correct) cultural standard of naming cookbooks in specific ways. How this separation is done could be completely isolated which is how Rubygems and PyPI do it (the name of the gem/distro has nothing do with the name of the thing you require/import), or more structured as in the case of Github. I prefer the Github way of prepending the username to the cookbook name to come up with the final identifier, but either could work.

Why do I think this is such a big deal? Lets say you need a cookbook to deploy mysql. You elect not to use the ChefInc one, so instead you write your own, but name it mysql anyway because that's the convention. You later go to release this publicly but find the name already taken and so have to choose between not releasing it or changing the cookbook name. Unfortunately because the cookbook name is used all over (roles, envs, other cookbooks, etc) this usually forces people down the path of not releasing things when the names conflict.

Why do I think this needs to be handled Now™? Because it will change all the unique identifiers everywhere, in the DB, UI, API, URLs, etc. They will probably all be longer which has ramifications for the UI, and changing them at all matters for the URLs and API. Handling this as part of the oldcommunity->supermarket transition means only one period of omgscary changes instead of two.

Cookbooks UI Wireframes Review

Hello everyone! In the spirit of collaboration, we'd like to open up review and critique of our work to-date on the redesigned cookbooks UI to the community. Please have a run-through of the wireframes at each of the links below and provide any feedback you have as comments in Invision.

Desktop Cookbooks Wireframes - http://invis.io/3KPCMO65

To leave a comment, press "c" or click on "Comments" in the bottom right of the window. To navigate through the screens:

  • Click “Applications” under "Categories" to view a category page.
  • Click on any “nodejs” to view a cookbook detail page.
  • On the cookbook detail page, you can click between the readme and dependencies tabs.
  • On any page you can click Cookbooks in the top nav to return to the main Cookbooks page.

Mobile Cookbooks Wireframes - http://invis.io/5MPCMNYB

To leave a comment, press "c" or click on "Comments" in the bottom right of the window. To navigate through the screens:

  • Click on Supermarket logo anytime to return to the main cookbooks page.
  • Click on “Applications” category to view a category page.
  • Click anytime on “nodejs” to view a cookbook detail page.
  • On the cookbook detail page, you can click through the details, readme and dependencies tabs.

Thank you!

Archlinux AUR as a model of a good community.

Archlinux (teh best linux ;) has a community repository for user packages. Its very similar in concept to the Chef Community site. Here's an example for a piece of software we're all used before.

So, take a look at those features

  • description
  • upstream url
  • category
  • license
  • original submitter
  • current maintainer
  • votes
  • creation time
  • modification time
  • complete list of external dependencies
  • a list to show which external packages require this package
  • original sources url

Pretty much everything you need to know about a package.

Additionally as a non-authenticated user, you can:

  • download a tarball of the raw package
  • view the raw metadata

If you authenticate, you get more available actions:

  • flag package as out of date
  • vote for package
  • subscribe to new comments

Take a look at the User Guidelines, and the Trusted User Guidelines. The difference between the two is that trusted users get more privilege in the community and have the ability to move things around.

The 'flag package as out of date' is the important thing here. A user may stop maintaining a package for any number of reasons. We don't want that package to name-squat and force users to fork and resubmit under a new name. So, users can flag the package as out of date. The maintainer of the package is notified and if after some time does not take action you can then mail a list and get TU's to take action.

So, now that I've duplicated some amount of the AUR docs, I urge you to go read them. I think it could work out as a great model for the new community site. The AUR docs are available under the GNU FDL.

🙈 🙉 🙊

Document Process in README

Put something in the README about where the work being done is being tracked. GitHub Issues? LeanKit? Pivotal? HuBoard? Trello? I have no idea right now.

Basic implementation of /v1/cookbooks

For now, we won't implement support for any of the pagination query parameters, and will simply render a response corresponding to an empty list:

GET /v1/cookbooks

{ "items": [], "start": 0, "total": 0 }

Expose dependency API endpoint

The new community site should expose an API endpoint that lists all uploaded cookbooks and their dependencies. We should use an API format (JSON) that corresponds to the Berkshelf API. This must be a single-page JSON file (no pagination).

Benefits

  1. Running the Supermarket internally doubles as a Berkshelf source endpoint (no need for a Berkshelf API server)
  2. Allows dependency solvers (like depsolver, solve, librarian, etc) to have a single authoritative source

Drawbacks

  1. Expensive operation for large numbers of cookbooks
  2. Need to implement a caching layer
  3. Need background jobs for processing

Considerations

  1. Security - when running the cookbook site internally, should all users be able to see all cookbooks?
  2. Delay - what is an appropriate amount of time until the cache is valid (since it will not be immediately)?

Curry - Pull Request CLA Verification Checker

Curry checks that committers in a GitHub Pull Request have signed Chef's CLA in Super Market.

Pull Requests that relate to this:

Intro

The general goal of curry is to verify that committer(s) opening a pull request in a Chef Inc. repo have signed a CLA. If they have signed a CLA, Super Market will leave a comment letting Chef Inc. know that the user has signed a CLA. If they have not, Super Market will leave a comment letting Chef Inc. and the committer(s) know they have not signed a CLA, while instructing the committer(s) to sign a CLA. When the Pull Request is opened, a ticket is opened in the ticket tracking system being used (in Chef's case, JIRA).

Major parts of Curry include:

  • Ability for Chef Admins to specify the repositories (and projects in corresponding ticket tracking system) that notify Super Market when a Pull Request was opened and updated. This let's GitHub know what repositories it should be the hub for when sending POSTs to Super Market via PubSubHubbub.
  • Handling POSTs to the Super Market API end point from GitHub when a Pull Request is opened and updated.
  • Commenting on Pull Requests based upon the committer(s) CLA verification status.
  • Opening a ticket in the ticket tracking system with the information surrounding the Pull Request.
  • If committer(s) had not signed a CLA when the Pull Request was opened but sign a CLA, Super Market will leave another comment in the Pull Request letting Chef Inc. know that a committer has signed a CLA (and what committers still need to sign a CLA).

Flow diagram of the process.

Information

Implementation Details

  • Super Market will subscribe to a GitHub repository Hub to receive POST requests at Super Market API end point when a Pull Request is created or updated in the GitHub repository. This will be using the PubSubHubbub protocol (Hubbub for short).
  • There will be an interface for managing what GitHub repositories Super Market is subscribed to.
  • Interfacing with JIRA (the current issue tracker) with the Jira Ruby gem to open issues when a Pull Request is opened on a subscribed repository.
  • Leaving comments on subscribed GitHub repositories with the Octokit.rb gem.
  • Use Sidekiq to process background jobs.

Approach

  1. Spec out and develop interface for managing GitHub repository subscriptions.
  2. Create API endpoint to receive Hubbub updates from the GitHub repository.
  3. Handle checking committers in the Pull Request to see if they have signed a CLA.
  4. Use Octokit to leave a comment on the Pull Request based upon their CLA signing status.
  5. Handle when committers have not signed a CLA but then sign a CLA.
  6. Use the JIRA Ruby gem to open an issue in the corresponding project.

Comments from the original Gist

@gabeweaver said:

One thing I think we should discuss with Chef:

Given that they are moving towards using LeanKit internally, it seems like JIRA is just an added layer of complexity in managing and tracking work to be done. I'm assuming Chef will be using the "Portfolio" version on LeanKit. If that's the case, then they support a really nice GitHub integration:

"Automatically add cards to designated boards as GitHub issues are created. Once cards reach the final lane or get archived, the GitHub issues are marked resolved. Configure destination boards/lanes, source item to destination card types and priorities mapping."

And since PRs also create GitHub issues, it seems like a Win/Win for reducing complexity and simplifying the workflow, not to mention reducing the barrier to entry and things for contributors to track.

@sethvargo said:

Can we use the commit status API instead? I think a comment is intrusive.

&&

Also, we probably want a batch job that goes through existing PRs and "rechecks" the status. Maybe that's a v2 though

@smith said:

I'm with @sethvargo on using the commit status API. Are there any reasons why we wouldn't do that and use comments instead?

As for checking existing PRs, the ideal solution might be that when a somebody signs a CLA, see if there are any open PRs that Curry has previously seen as unresolved by that user and go put a new message on them. Agreed that that's probably a v2 feature that has lots of unanswered questions.

IMO it might be preferable to leave JIRA completely out of this release, since there might be a lot of complexity around the avoidance of opening duplicate issues. All of the linking we now do between JIRA and GitHub is now manual, and it may have to stay that way for a while.

The LeanKit/GitHub integration sounds really cool, but lets learn how to make a board and use LeanKit before we get there.

Overall this all looks sound, and it a huge improvement over having a human do it.


@gabeweaver @sethvargo @smith I have moved the content and comments from the original Gist to here. I think GitHub Issues are a better place to document discussion because we will get notified of comments, they are tied to the repository and and the discussions should be easier to find.

Create CONFIGURING.md guide to configuring the application locally

The README is getting a bit long, and I think it would make sense to create a document specifically for configuring the application locally. This would explain in depth what needs to be configured, how to configure it and why it is there.

This file should be linked to from within the README.

Downloads shouldn't use a redirect

curl doesn't follow redirects by default, so using them for downloads can be problematic. It might be nicer to have them link directly, and pull download counts by parsing the S3 access logs.

Allow users to view a cookbook

  • Implement basic UI around name and installation
  • Display the README
  • Make Download link work
  • Show released versions and their related info*
  • Show download stats for all versions and latest version
  • Show updated/created timestamps
  • Display the cookbook maintainer
  • Link to the source if it exists
  • Display the cookbook's platforms
  • Display the cookbook's license
  • Determine if having multiple READMEs in different formats is prevalent among existing cookbooks (some code in the old community site suggests it could be).

This is issue is closes #188 and #187.

*Note from @danvolkens when clicking a specific cookbook version on the cookbook show: output the download count, last updated at, and a link to download version

The mock-up for this view: https://projects.invisionapp.com/share/DGP7AUT4#/screens/17695290?maintainScrollPosition=false/preview

Pull request for this issue: #202

supermarket cookbook cleanup

A few remaining issues to cleanup, and leaving them here since PR comments can get lost to the ether:

  • Create an 'apps' data bag with a 'supermarket' item. Load this up in the _applicaiton recipe. Possibly create a helper method that adds it to the node's run state to pass around between recipes.
  • Set the deploy directory to /srv/supermarket instead of /var/www/supermarket.
  • Set the supermarket user's home directory to /srv/supermarket.
  • Render the sidekiq.yml as a file resource with content node['sidekiq'].to_hash.to_yaml. We may want to namespace the config attribute separate (node['sidekiq']['config']).

Allow users to download a cookbook

Users should be able to download a tarball of a cookbook from the community site. We should also track download statistics when downloads are performed via either Knife or through the community site API.

Allow users to authenticate with oc-id

Currently users authenticate and register with their email and password. We want to transition this to OAuth2 with oc-id (Chef ID) as the provider. This will make the account management process quite a bit easier and remove any of the nastiness that the current community site does.

  • Change auth process to OAuth instead of email and password
  • Explore using devise-omniauthable or omniauth for auth
  • Make oc-id the OAuth2 provider

Data Migration, User Authentication and Every Question Ever

@bcobb, @tristanoneil and I had a lil' hang out to figure out what we want to get out of the meeting tomorrow where we are talking about auth and data migration. Here is that list:

  • how does authentication currently work?
  • how are the pem keys handled and what role do they play?
  • how should authentication work?
  • what impact does supermarket have on chef server? @nathenharvey mentioned that current community site is legacy and chef server depends on it.
  • can we get a schema dump of the current site? getting it running locally is painful. - @bcobb
  • what data is getting migrated? pem keys? cookbooks? users? users following a cookbook?
  • where do the current cookbook files live? where should live with supermarket? do we want to move them or are they staying in the same place?
  • do we have to stick with mixlib for authentication? is it 👌 or is there a better solution?
  • what constitutes a valid cookbook? is it just a valid metadata.rb or does it have to actually do something? - @tristanoneil
  • what role does JIRA currently play within cla signing? - @brettchalupa
  • how are we going to handle missing cla signatures during the migration if that occurs? - @brettchalupa

Feel free to answer questions here if you can or add additional ones. This is more or less a place where we can reference this list and log any notes.


As @bcobb said:

We want the transition from the existing community site to supermarket to be as seamless from the end-user's perspective as possible. That is, it should appear to the user that the site has merely been redesigned; it is an implementation detail that it has been rebuilt from the ground-up. The biggest unknown to this end is authentication. We'd like to understand how the existing community site fits into the larger Chef authentication picture, and we'd like to discuss strategies for getting Supermarket to perform that same role. We'd also like to discuss general strategies for migrating all of the existing community site's data from MySQL to Postgres. Finally, we've been crunching CLA CSVs and want to discuss next steps.

Allow users to search for cookbook by metadata

Users can search for a cookbook by meta data (Name, Owner, Description, Platforms, Category) from a single, “smart” text field so that I can find a specific cookbook in Supermarket

Add "Contribute To Supermarket" Section

This section should be able to render GHFMD so we can easily update the content as we go. Ideally there would be an overview section that has basic text content, then we'll also want to support adding weekly updates in a similar fashion to adding a blog post. This will replace delivering weekly updates via email and include the broader community in our weekly progress. For now, this will be limited to the Supermarket project. We'll need to:

  • Design up the view(s) (Dan)
  • Do the backend work necessary to support the views
  • Add the content (Gabe)

There is a rough start on the content here

Trello Card

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.