Migrate Travis content builds to the hosted Deconst Strider instance

[smashwilson]

Once deconst/deconst-docs#7 is live, we'll likely want to migrate the existing Travis builds to Strider because:

1. It'll give you a nice, dashboard view of the status of all of the documentation builds.
2. Your build will need to be on Strider to actually use the PR builder.

For each repository here, we'll need to:

1. Grant @rackernexus "admin" access to the repository as an external contributor.
2. Add an entry to content-repositories.json file in this repository;
3. Remove the Travis builds from the content repositories;
   • Delete the .travis.yml and script/cibuild files
   • Deactivate the build in the Travis UI or with the travis CLI.
4. Change the Travis build badge to a Strider build badge.

The full documentation for adding new content repositories is on deconst.horse.

• docs-developer-blog (Requires special handling; see rackerlabs/docs-developer-blog#190.)
• docs-quickstart
• docs-core-infra-user-guide
• rs-heat-docs
• docs-cloud-images
• docs-cloud-load-balancers
• docs-cloud-block-storage
• docs-cloud-dns
• docs-cloud-cdn
• docs-cloud-databases
• docs-cloud-backup
• docs-cloud-orchestration
• heat-resource-ref
• docs-cloud-rackconnect
• docs-cloud-queues
• docs-cloud-networks
• docs-cloud-big-data
• otter
• docs-cloud-servers
• docs-cloud-files
• docs-cloud-metrics
• docs-cloud-identity
• docs-cloud-monitoring
• docs-barbican
• docs-dedicated-networking
• docs-common
• docs-rpc
• docs-dedicated-vcloud
• docs-redhat-osp

/cc @meker12, @catlook

[smashwilson]

By the way, @meker12, I'm hesitating to flip the switch on everything all at once because I'm guessing that we'll see some performance problems and growing pains on our Strider instance.

It seems to be okay so far, though. There are a few small glitches I'm trying to track down before I do the next batch.

[meker12]

Thanks for the info. It's so easy :-). I'm working on internal doc migrations now, so don't have so much bandwidth. If we need to get the Strider build ASAP on a project, this info is helpful. Will leave it to you or other writers that need it right away.

+1 on not flipping all at once to avoid Strider issues.

Also, I expect that you'll send a note to everyone about the feature when you're ready. Very excited about this feature. People are going to love it.

[smashwilson]

Also, I expect that you'll send a note to everyone about the feature when you're ready.

Well, I'm expecting that people will notice (a) the pull request that migrates their build and (b) the preview comments that start appearing on their pull requests.

[meker12]

You might want to send a note for 2 reasons: 1) Announce exciting new feature completed. 2) Provide people with explicit context for the things they are noticing and also advise about where to report any issues. It's up to you, of course.

[meker12]

@smashwilson In the content-repositories.json file, do you think it might be helpful to group by categories (sdk, cloud, rpc) and also alphabetize in each?

Hope you don't mind that I updated step 2 of the migration instructions to link to the content-repositories.json file.

[smashwilson]

@smashwilson In the content-repositories.json file, do you think it might be helpful to group by categories (sdk, cloud, rpc) and also alphabetize in each?

Alphabetizing, sure. That's a good way to avoid merge conflicts anyway. JSON objects are unordered collections anyway so we can do that now.

Grouping by categories would require changes to the parsing in the strider-deconst-control plugin and wouldn't actually add any information for the plugin to use. Maybe I could add a "comment" type that's ignored so we could do:

[
  { "kind": "comment", "group": "sdks" },
  { "kind": "github", "project": "rackerlabs/sdk1" },
  { "kind": "github", "project": "rackerlabs/sdk2" },

  { "kind": "comment", "group": "cloud" },
  { "kind": "github", "project": "rackerlabs/cloud1" },
  { "kind": "github", "project": "rackerlabs/cloud2" }
]

(Once again it sucks that JSON doesn't support comments.)

Hope you don't mind that I updated step 2 of the migration instructions to link to the content-repositories.json file.

Nope, that's great. Thanks!

[meker12]

@smashwilson

For planning purposes, do you think we can just continue adding the API doc repos as we update the contributor collateral, which has been updated to reflect the PR builder. Or do you have a cadence for adding these builds to avoid overloading Strider.

I know that you had planned to write a script, but since we are in the repos anyway, and you made the process of adding the Strider build dead easy, should we just do it manually?

If you would prefer to script it, let us know, and we can hold the PRs to update the contributor collateral until the Strider build has been enabled.

[smashwilson]

Hold off for now - I'm currently working on deconst/deploy#107 to give us more breathing room in the staging services and on the build host. We should hold off on adding any more builds until I get that shipped to production.

Once that's in place and we're more stable, it would be awesome if you wanted to do it manually instead 😄

Thirty repositories is well over my threshold for doing something by hand, but that's just me. 😉

[meker12]

heh-- well we have 3 people, and are in the repos for other things all the time, so it's bite size changes.

So when deconst/deploy #107 ships -- is that our signal to migrate the rest of them? Also, is there any reason not to add nexusracker to the DevDocs team. Then, that ID would have access on all the builds.

[smashwilson]

Correct. It'll be shipped a while after I merge the pull request - I'll update this issue once it's out and looking stable.

[smashwilson]

@meker12: deconst/deploy#107 is now live. We're now running up to 8 simultaneous builds on on a beefier box, and 4 staging pods behind the staging load balancers. 🎉

Go ahead and start migrating builds at will! If we hit another breaking point, we'll deal with it when we get there.

[meker12]

Nice!

@smashwilson Questions about updates for builds: Can you add more than one at a time? (I added 3. -- eek!)

After you add a product, where do you see whether the addition is successful. I tried to view the Strider build log for nexus-control, and it says I'm not authorized.

[smashwilson]

Can you add more than one at a time? (I added 3.)

Yup. The control repo build will create content builds for any projects that are listed in the configuration file but not already in Strider.

After you add a product, where do you see whether the addition is successful. I tried to view the Strider build log for nexus-control, and it says I'm not authorized.

Really? At https://build.developer.rackspace.com/rackerlabs/nexus-control/ ?

While nexus-control's ACL isn't automatically managed yet (see deconst/strider-deconst-control#21) you're definitely listed as a collaborator; I just double-checked.

[smashwilson]

I just disabled the Travis builds for the three repos you added yesterday, @meker12:

~/writing/docs-developer-blog docker:dev venv:ansible-deconst (master=) 
$ cd
~ docker:dev venv:ansible-deconst 
$ travis disable -r rackerlabs/rs-heat-docs
rackerlabs/rs-heat-docs: disabled :(
~ docker:dev venv:ansible-deconst 
$ travis disable -r rackerlabs/docs-cloud-images
rackerlabs/docs-cloud-images: disabled :(
~ docker:dev venv:ansible-deconst 
$ travis disable -r rackerlabs/docs-cloud-load-balancers
rackerlabs/docs-cloud-load-balancers: disabled :(

[meker12]

@smashwilson That's great. Thanks for showing me the code :-)

[smashwilson]

You can also do it through your Travis profile; find the repository under "Rackspace Hosting" and flip the switch to "off". The Travis CLI saves you a little scrolling, though.

[meker12]

Yeah, I had found that already :-) I enjoy the command line these days. Faster and I don't have to figure out someone's conception of my workflow in the (many, many, different UIs).

[smashwilson]

Concur completely 😁 It's also easier to throw together little scripts of bash or terrible one-off Ruby to automate things that way.

[meker12]

All done 🎱