Auto update gh-pages branch when docs are updated. #44

m-murad · 2017-10-19T23:09:21Z

This PR is relate to #40
This will auto update gh-pages branch when master branch is updated.

m-murad · 2017-10-19T23:10:22Z

Travis needs to be enabled for the project and an API key needs to be added in the travis console.

m-murad · 2017-10-19T23:22:13Z

deploy.sh

+    exit 0
+fi
+
+git clone --quiet --branch=gh-pages https://oliverroick:[email protected]/cadasta/api-docs  /home/travis/build/cadasta/docs-branch


@oliverroick
You need to generate an API key and use it in travis.

Read about generating an API key here.

Once you generate the API key open the project in travis-ci.org.

In settings tab add an environment variable. Name the variable API_KEY and value the key you generated.

I'll create a bot user for these tasks, that build won't break when a user is removed from the team.

oliverroick

Hi @m-murad, thanks for getting automated deploys started. That will make the process much easier for us.

I left a few comments that I would like you to address. Once we have accepted your changes, I'll enable the project on Travis so we can see if the project is built correctly.

oliverroick · 2017-10-26T10:10:10Z

deploy.sh

@@ -1,29 +1,26 @@
 #!/bin/bash

-rm -rf dddocs
-rm -rf docs-build
+if [ "$TRAVIS_PULL_REQUEST" != "false" -o "$TRAVIS_REPO_SLUG" != "cadasta/api-docs" ]; then


This condition looks wrong. The first part excludes all builds on pull requests, the second part excludes all builds that are not triggered from cadasta/api-docs, which will never become false, since all builds will always be triggered from cadasta/api-docs.

Connecting both with an OR operator (you're using -o) means the build will never exit.

As I suggested in my comment to the corresponding issue, I would use:

if ["$TRAVIS_TAG" != "false"]

That way we only ever deploy when a new version has been tagged.

"$TRAVIS_REPO_SLUG" != "cadasta/api-docs"
This condition is for a scenario where commit or PR is made on the forked copy of this repository.
e.g. if I'm making the changes on my own copy of the repository i.e. m-murad/api-docs the auto update will be skipped.

oliverroick · 2017-10-26T10:39:13Z

deploy.sh

+    exit 0
+fi
+
+git clone --quiet --branch=gh-pages https://oliverroick:[email protected]/cadasta/api-docs  /home/travis/build/cadasta/docs-branch


I'll create a bot user for these tasks, that build won't break when a user is removed from the team.

oliverroick · 2017-10-26T10:41:03Z

deploy.sh

-echo "Done."
+git add .
+git commit -m "Deploy docs"
+git push origin gh-pages --quiet


For the time being, can we push this to another branch, maybe gh-pages-test? I want to see the script in action before we start overwriting docs website.

Once your changes are approved, I'll change that back.

oliverroick · 2017-10-26T10:43:13Z

deploy.sh

 mkdir docs-build
-npm install


I'm not too familiar with building Node projects on Travis. I'm assuming that Travis always runs npm install by default?!

Yes it does. You can check it here.

oliverroick · 2017-10-26T10:45:45Z

deploy.sh

-rm -rf docs-build
-echo "Done."
+git add .
+git commit -m "Deploy docs"


Is there a way to use the content of $TRAVIS_TAG here to get nicer commit messages? For example, if we tag 1.0.1 that we end up with the commit message Deploy docs v1.0.1.

I'm still not able to understand what you are trying to say.

I checked this repository but no tag has been created for this repository. Maybe if you can explain it to me.

What we can do we can use the commit message of the commit that is being build or the branch of the pull request.

Yes, no tags have been created so far. But we will create tags in the future to kick off the deployment process.

So whenever we think that what is on master is ready, we create a new tag, which deploys the docs. I don't want to deploy the docs with every push to master for a simple reason: When we build features for the API and document the changes, the changes to the documentation might be merged to master before the changes to the API are released. If we deploy with every push to master, the documentation won't match the current API and we can avoid that by tagging versions on master and deploy only when a new tag is created.

For that we can do something else.

Once a TAG is created at cadasta/cadasta-platform i will right a script that will create the TAG in this repository as well.

This way the docs will remain updated after every commit and when a new tag is created for cadasta-platform it will automatically create a tag for api-docs.

I'm suggesting updating the docs after every commit because after my PRs #37, #39, #36
The docs are still not updated to reflect the changes.

Creating a TAG at cadasta/cadasta-platform and cadasta/api-docs at same time will makes sense. That way we can also corrosponde every version of cadasta-platform to its doc

I'm suggesting updating the docs after every commit because after my PRs #37, #39, #36
The docs are still not updated to reflect the changes.

We simply forgot; I'll take care of the deployment tomorrow. Updating the docs after every commit is still not an option.

Once a TAG is created at cadasta/cadasta-platform i will right a script that will create the TAG in this repository as well.

That's something we can do further down the line. I'd say we focus on this PR first and then look at follow-ups.

m-murad · 2017-10-29T17:56:38Z

@oliverroick
Correct me if I'm wrong.
What you want is that - every time you create and push a tag, the gh-pages branch should be updated from the code thats in master branch?

oliverroick · 2017-10-30T07:37:03Z

Yes that's correct

m-murad · 2017-10-30T12:28:18Z

@oliverroick
I have updated the PR.
The gh-pages branch will only be updated if a TAG is pushed to the repository.

The commit message will be of the format
"Docs updated for TRAVIS_TAG"
eg Docs updated for v1.2

m-murad · 2017-11-02T22:40:32Z

I have fixed this. Please review

…

On Oct 30, 2017 1:07 PM, "Oliver Roick" ***@***.***> wrote: Yes that's correct — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQdmZNimzn6M4_VIDRaiJ_EaC_4bm2dTks5sxXyggaJpZM4P_-5Z> .

oliverroick · 2017-11-03T08:08:30Z

It's on my list. I'll review when I get to it. It's not the highest priority at the moment

m-murad commented Oct 19, 2017

View reviewed changes

m-murad mentioned this pull request Oct 23, 2017

Automating the process of deploying API docs. #40

Open

oliverroick requested changes Oct 26, 2017

View reviewed changes

m-murad added 3 commits October 30, 2017 17:28

Added travis.yml

49e4378

Updated deploy.sh to auto-update docs when tag is created

231eafb

Temp commit verify the script

2ac11c7

m-murad closed this Aug 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Auto update gh-pages branch when docs are updated. #44

Auto update gh-pages branch when docs are updated. #44

m-murad commented Oct 19, 2017

m-murad commented Oct 19, 2017

m-murad Oct 19, 2017

oliverroick Oct 26, 2017

m-murad Oct 26, 2017

oliverroick left a comment

oliverroick Oct 26, 2017

m-murad Oct 26, 2017

oliverroick Oct 26, 2017

oliverroick Oct 26, 2017

oliverroick Oct 26, 2017

m-murad Oct 26, 2017 •

edited

Loading

oliverroick Oct 26, 2017

m-murad Oct 26, 2017

oliverroick Oct 26, 2017

m-murad Oct 26, 2017

m-murad Oct 26, 2017

m-murad Oct 26, 2017

oliverroick Oct 26, 2017

m-murad commented Oct 29, 2017 •

edited

Loading

oliverroick commented Oct 30, 2017

m-murad commented Oct 30, 2017

m-murad commented Nov 2, 2017 via email

oliverroick commented Nov 3, 2017

Auto update gh-pages branch when docs are updated. #44

Auto update gh-pages branch when docs are updated. #44

Conversation

m-murad commented Oct 19, 2017

m-murad commented Oct 19, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oliverroick left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m-murad Oct 26, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m-murad commented Oct 29, 2017 • edited Loading

oliverroick commented Oct 30, 2017

m-murad commented Oct 30, 2017

m-murad commented Nov 2, 2017 via email

oliverroick commented Nov 3, 2017

m-murad Oct 26, 2017 •

edited

Loading

m-murad commented Oct 29, 2017 •

edited

Loading