Deploy user docs via Travis on release

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.

[Xenonym]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Other, please explain: DevOps enhancement

Closes#688.

What is the rationale for this request?
Since we have implemented markbind deploy --travis, we can now deploy our own user documentation automatically on release with Travis.

What changes did you make? (Give an overview)
I added a deploy phase to .travis.yml that will build and deploy the user docs on release (a commit with a tag matching the pattern vx.x.x).

Testing instructions:

1. Pull this PR to your own fork, and test with Travis CI enabled.
   • Normal commits should test but not deploy.
   • Tagged commits matching vx.x.x should trigger the deploy stage. It will fail since GITHUB_TOKEN should not be set, but this is expected.

[damithc]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

[yamgent]

We can make this branch based instead of tag based. e.g., have another branch named release. Would that be possible/cleaner?

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

[damithc]

That would be possible too, we can do that. Although the branch would probably only be used specifically for deploying documentation (since it doesn't fit our current release flow, as version tags are superior to a dedicated release branch).

I see. Let's stick with the tags then.

[nicholaschuayunzhi]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

[Xenonym]

Have tested it and works. We would need to set up a GITHUB_TOKEN on travis for the repository and make sure only releases should have tags.

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

[yamgent]

As a precautionary measure, we should configure MarkBind/markbind.github.io.git so that only the Team Lead (@yamgent) has push permissions to it.

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

[nicholaschuayunzhi]

The actual account behind the pushing is actually @traviscibot though (see aefca73). Restricting the permission to just the bot isn't sufficient because anyone else could still invoke Travis for pushing.

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

[yamgent]

I believe the concern is specifically:

1. dev have their own fork of the repo
2. dev has set up travis for his fork
3. dev's fork's travis has GITHUB_TOKEN set
4. markbind.github.io.git allows pushes by any dev

Then a push to any branch on their fork with a tag matching vx.x.x would trigger a site rebuild on the live markbind site.

Got it, I got confused with how the GitHub tokens work, my apologies.

I don't think anyone on the @MarkBind/cs3282-developers team has push rights to markbind.github.io.git in the first place, so I think it should be fine.

[yamgent]

Works nicely, deployment of MarkBind documentation is now automated. 👍

But on a side note:

EDIT: Additionally, developers with travis set up on their fork, with their GITHUB_TOKEN set, should not push any tags that match the vx.x.x format. Unless we have push rights removed from markbind.github.io.git

There is actually a very simple solution to this, by using the repo options:

deploy:
on:
repo: MarkBind/markbind

While I have push rights to markbind.github.io, I still don't want my fork to do any deployment (it attempted to do that, but error-ed out because I didn't set GITHUB_TOKEN for my fork). So using the repo option will solve the problem of avoiding deployments on forks.