You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Say someone makes a PR adding a new tutorial to this site. We can review the code and all, but in order to see how it actually looks on the site, we'd have to manually git clone, npm install, npm run start on every pull request. If we don't, we could risk breaking the site, or deploying changes that we dont want to the site, or deploying changes that just don't look right, or are missing things.
So, this new feature would help fix that, by more easily letting us deploy a "staging" site that the PR makes.
Example
Person A, a random contributor to the tutorials site, sends in a PR (say, PR #920) that adds a new tutorial. Person B, a maintainer of this project, takes a look at the PR changes and think it looks good. Person B then comments on the PR saying /stage. This will trigger a Github Action that will take the code from the PR, runs it, builds a static site, and uploads it to http://os-ucsd.ucsd.edu/tutorials-staging/920. Now, Person B can verify that the code indeed does compile and runs correctly, as well as view a live version of the site to verify that everything looks good. If they find a problem, they can let Person A know on the PR. When Person A fixes the problem, Person B can then run /stage again to re-upload the PR code to /tutorials-staging/920. Once the PR is complete, Person B can merge in the PR, and Person B can later ssh into the server and remove the tutorials-staging/920 directory (or maybe this can also be done automatically to, idk).
So the review process would be like:
Contributor opens a PR
Reviewer does a quick review of content/code to make sure nothing is obviously bad
Reviewer comments /stage, Github Action picks it up and creates a staging site
Github actions comments on the PR with a link to the staging site when succesful
Reviewer does a review on the generated site, makes sure everything looks good
If feedback is given and the contributor fixes it, then reviewer runs /stage again to update the staging site
Once ready, reviewer merges the PR
Sometime later, Reviewer cleans out old staging site
The text was updated successfully, but these errors were encountered:
Say someone makes a PR adding a new tutorial to this site. We can review the code and all, but in order to see how it actually looks on the site, we'd have to manually
git clone
,npm install
,npm run start
on every pull request. If we don't, we could risk breaking the site, or deploying changes that we dont want to the site, or deploying changes that just don't look right, or are missing things.So, this new feature would help fix that, by more easily letting us deploy a "staging" site that the PR makes.
Example
Person A, a random contributor to the tutorials site, sends in a PR (say, PR #920) that adds a new tutorial. Person B, a maintainer of this project, takes a look at the PR changes and think it looks good. Person B then comments on the PR saying
/stage
. This will trigger a Github Action that will take the code from the PR, runs it, builds a static site, and uploads it tohttp://os-ucsd.ucsd.edu/tutorials-staging/920
. Now, Person B can verify that the code indeed does compile and runs correctly, as well as view a live version of the site to verify that everything looks good. If they find a problem, they can let Person A know on the PR. When Person A fixes the problem, Person B can then run/stage
again to re-upload the PR code to/tutorials-staging/920
. Once the PR is complete, Person B can merge in the PR, and Person B can later ssh into the server and remove thetutorials-staging/920
directory (or maybe this can also be done automatically to, idk).So the review process would be like:
/stage
, Github Action picks it up and creates a staging site/stage
again to update the staging siteThe text was updated successfully, but these errors were encountered: