Christopher wrote:
On Wed, May 20, 2015 at 10:08 PM, Christopher<[email protected]> wrote:
On Wed, May 20, 2015 at 7:39 PM, Josh Elser<[email protected]> wrote:
Christopher wrote:
The other half of me wanting to fork off this convo is that there's also
more to making a release than just making the release candidate. I
probably
had 30+ commits to CMS over the past week (granted some of which were
me
just editing content on CMS), but we have a lot of steps which are now
just
copying files from the release, committing to the site repo. I'd love
to see
more done for automation here that can reduce the pain for the post-RC
work.
[snip]
+0.5 to that. I'm willing to help a bit here, but it's a bit daunting,
and it's not even clear to me where we can automate, especially with
CMS being involved as a middle-man.
Yeah, I have _no idea_ what this kind of automation would look like. Trying
to keep it somewhat decoupled from CMS itself would be good (as it may go
away in the future -- or at least look different). It was just a pain point
that I noticed. I went back and forth picking files from the source release,
putting them in CMS, verifying they rendered right, etc.
One thing you could have done is update all the files before clicking
"commit". CMS is basically a web interface for a local SVN checkout.
You can update many files in this local SVN checkout, examining each
preview render, before ultimately clicking "Commit" which initiates a
final rendering to the staging site. You definitely don't have to
commit one file at a time.
Incidentally, one of the reasons I hate CMS is that I have no option
to do a full local render to test the CSS, links, markdown rendering,
etc.. There also isn't an option to publish some changes, but not
others. It's either publish what's on "staging" or not. There's no
half-way. So, if somebody fixed a link while we were staging changes
for a release, they wouldn't be able to publish that fix without also
including the other staged changes.
You can run the CMS locally to see changes. I did this in the past with
success when we switched to the bootstrap-backed version of the site.
The only problem is that all of our paths are relative so you have to
host it at the root of a vhost.
