Closed ultrasaurus closed 9 years ago
The idea is that individual projects can add a project yaml file in https://github.com/18F/data-private/projects and it would override what's in private/projects.yaml which in turn overrides the dashboard/_data/projects.yml
I pushed my example data here: https://github.com/18F/data-private/tree/midas-project-file but didn't do a pull request of that, until I hear back on this idea
From #179:
don't know what Jekyll will do with a collision between NAME.yml and NAME/
Not sure if this is what you meant, @mbland but I think it is: creating _data/projects/<project>.yaml
overrides projects.yml
as the source of site.data.projects
and thus breaks the template. :neutral_face:
I like this idea and am definitely sympathetic to the issue and so will leave this and #179 open so we can iterate on the idea. (Though, it's probably a better idea to do that iterating in data-private
.)
Proposal: Write a script that essentially shatters the existing projects.yaml
and creates all the individual project files in data-private. Then use HashJoiner to sew them all back into one data file for deployment to various different spots.
Working through the following error:
Assuming a myra.yml
file in _data/private/projects/
with the name
matching the myra
entry in _data/private/projects/
.
./go update_data
./import-public.rb:26:in `[]': no implicit conversion of String into Integer (TypeError)
from ./import-public.rb:26:in `block (2 levels) in <main>'
from ./import-public.rb:26:in `index'
from ./import-public.rb:26:in `block in <main>'
from ./import-public.rb:19:in `each'
from ./import-public.rb:19:in `<main>'
I tested the pull request with a midas.yml
file in dashboard/_data/private/projects
- project: "Midas"
name: midas
github:
- 18F/midas
description: Midas is a platform that facilitates collaborative work worldwide. Individuals can create projects, propose working groups, or assemble "tiger teams" to act on their ideas. Anyone can also post tasks online and people with the requisite skills can respond and complete the task.
partner:
- General Services Administration
- Department of State
- Department of Health and Human Services
partners:
stage: beta
impact: "2 million federal employees"
milestones:
- "October 2014: GSA hosts Midas open source hack night in DC"
- "October 2014: DigitalGov Open Opportunities pilot starts"
- "September 2014: GSA OCSIT signs MOU for Open Opportunities to move to Midas platform"
- "September 2014: 18F launches https://midas.18f.us for use by early adopters"
- "June 2014: State Department launches Alpha as Crowdwork"
- "May 2014: HHS launches Alpha as FairTrade"
- "January 2014: 18F begins work on project"
- "June 2013: State Department begins project Discovery stage with Presidential Innovation Fellows"
contact:
- midas@gsa.gov
stack: "JavaScript (Node/Sails, Backbone), CSS, Chef"
team: sarah, david, joe, dhcole
licenses:
midas: Public Domain (CC0)
links: https://midas.18f.us/
blog:
- midas
status:
@gboone what was the content of the myra.yml file you were testing?
Okay, my mistake was I didn't make a full copy of the data from `projects.yml'.
If we merge this today we'll want to let product owners know that they need to copy the full entry from projects.yml
into the new projects/<project>.yml
file. That is, a myra.yml
that looks like this:
---
- project: myRA
name: myra
github:
- 18F/18f.gsa.gov
Will not merge the new github repo into the existing projects.yml
entry. It will completely overwrite it. Personally, I'm not a fan of that, but you're the product lead, so if you don't think people will be confused I'm okay with merging it.
@gboone looks like our comments cross in transit. I'm a fan of having all my data in one place -- I would delete the midas entry from the projects.yml in my first commit, then after that, I wouldn't have any collisions
Thanks!
@gboone:
Proposal: Write a script that essentially shatters the existing projects.yaml and creates all the individual project files in data-private. Then use HashJoiner to sew them all back into one data file for deployment to various different spots.
If you can bang that out as part of this PR, you can check in the script and the "shattered" files all in one shot.
Yeah, I'm thinking that might be better done in the data-private repo where people will be editing them. Doesn't mean I won't do it (soon), just not in this PR.
@gboone Shall you open an issue in data-private, or should I?
I can do it.
Thanks!
Thanks for the contribution!
this is an idea of how to approach #179