danxi / github-upload

What is Travis CI?

Travis CI is a hosted continuous integration platform that is free for all open source projects hosted on Github.

With a file called .travis.yml, you can trigger automated builds with every change to your repo.

How to use Travis CI?

1. Sign in to Travis CI with your GitHub account.

2. Go to your profile page and choose a repository to run Travis CI builds.

3. Put a file called .travis.yml, which tells Travis CI what to do, in the root of your repository.

4. Edit the empty NewUser.txt file by adding your name to the empty file. Add the file to git, commit and push, to trigger a Travis CI build.

$ git add -A
$ git commit -m 'Testing Travis CI'
$ git push

1. Wait for Travis CI to run a build on your repository, check the build status and notice that the build fails. (Travis CI sends you an email when this happens)

.travis.yml

your .travis.yml file may tell Travis CI:

• What programming language your project uses
• What commands or scripts you want to be executed before each build (for example, to install or clone your project’s dependencies)
• What command is used to run your test suite
• Emails, Campfire and IRC rooms to notify about build failures

You can use lint.travis-ci.org to verify this file.

Note that for historical reasons .travis.yml needs to be present on all active branches of your project.

Specifying Runtime Versions

One of the key features of Travis CI is the ease of running your test suite against multiple runtimes and versions. Specify what languages and runtimes to run your test suite against in the .travis.yml file.

A list of languages and runtimes Travis CI supports.

language: node_js
node_js:
  - "4.1"

The above .travis.yml tells Travis CI that this project is written in Node v4.1 .

The Lifecycle

A build on Travis CI is made up of two steps:

• install: install any dependencies required
• script: run the build script

You can run custom commands before the installation step (before_install), and before (before_script) or after (after_script) the script step.

You can perform additional steps when your build succeeds or fails using the after_success (such as building documentation, or deploying to a custom server) or after_failure (such as uploading log files) options. In both after_failure and after_success, you can access the build result using the $TRAVIS_TEST_RESULT environment variable.

The complete build lifecycle is:

1. before_install
2. install
3. before_script
4. script
5. after_success or after_failure
6. after_script
7. OPTIONAL before_deploy
8. OPTIONAL deploy
9. OPTIONAL after_deploy

Customizing the Installation Step

Travis CI uses the default dependency installation commands depend on the project language to install the dependencies. For Node projects, the default dependency installation commands is npm install.

install:
  - npm install

You can specify your own script to run to install whatever dependencies your project requires in .travis.yml.

install: ./install-dependencies.sh

When one of the steps fails, the build stops immediately and is marked as errored.

You can skip the installation step entirely by adding the following to your .travis.yml.

install: true

Customizing the Build Step

The default build command depends on the project language. You can overwrite the default build step in .travis.yml:

script:
  - bundle exec rake build
  - bundle exec rake builddoc

When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well, and accumulates the build result.

If your first step is to run unit tests, followed by integration tests, you may still want to see if the integration tests succeed when the unit tests fail.

You can change this behavior.

script: bundle exec rake build && bundle exec rake builddoc

This example (note the &&) fails immediately when bundle exec rake build fails.

If any of the commands in the first four stages of the build lifecycle return a non-zero exit code, the build is broken:

• If before_install, install or before_script return a non-zero exit code, the build is errored and stops immediately.
• If script returns a non-zero exit code, the build is failed, but continues to run before being marked as failed.

The after_success, after_failure, after_script and subsequent stages do not affect the the build result.

Build Timeouts

Because it is very common for test suites or build scripts to hang, Travis CI has specific time limits for each job. If a script or test suite takes longer than 50 minutes (or 120 minutes on travis-ci.com), or if there is not log output for 10 minutes, it is terminated, and a message is written to the build log.

There is no timeout for a build; a build will run as long as all the jobs do as long as each job does not timeout.

Building Specific Branches

Travis CI uses the .travis.yml file from the branch specified by the git commit that triggers the build.

You can tell Travis to build multiple branches using blacklists or whitelists. Specify which branches to build using a whitelist, or blacklist branches that you do not want to be built:

# blacklist
branches:
  except:
    - legacy
    - experimental

# whitelist
branches:
  only:
    - master
    - stable

If you specify both, only takes precedence over except. By default, gh-pages branch is not built unless you add it to the whitelist.

You can use regular expressions to whitelist or blacklist branches:

branches:
  only:
    - master
    - /^deploy-.*$/

If you don’t want to run a build for a particular commit, because all you are changing is the README for example, add [ci skip] to the git commit message. Commits that have [ci skip] anywhere in the commit messages are ignored by Travis CI.

Deploying your Code

An optional phase in the build lifecycle is deployment.

When deploying files to a provider, prevent Travis CI from resetting your working directory and deleting all changes made during the build ( git stash --all) by adding skip_cleanup to your .travis.yml:

deploy:
  skip_cleanup: true

You can run steps before a deploy by using the before_deploy phase. A non-zero exit code in this command will mark the build as errored.

If there are any steps you’d like to run after the deployment, you can use the after_deploy phase.

Building Node Project

Provided Node.js Versions

• 4.1.x (support provided on demand)
• 4.0.x (support provided on demand)
• 0.12.x (support provided on demand)
• 0.11.x
• 0.10.x (recent stable release)
• 0.8.x
• 0.6.x
• iojs (recent stable release of io.js)

Travis CI uses nvm to specify Node versions. Newer releases not shown above may be used if nvm recognizes them.

language: node_js
node_js:
  - "4.1"
  - "4.0"
  - "0.12"
  - "0.11"
  - "0.10"
  - "0.8"
  - "0.6"
  - "iojs"

This will make Travis CI run your tests against the latest version 0.6.x, 0.8.x, 0.10.x, 0.11.x, 0.12.x, 4.0.x, and 4.1.x branch releases, as well as the latest io.js stable release.

Specifying node or stable will run using the latest stable Node.js release and specifying iojs will run using the latest stable io.js release.

Specifying only a major and minor version (e.g., “0.12”) will run using the latest published patch release for that version. If a specific version is not needed, It is encouraged to specify node and/or iojs to run using the latest stable releases.

Dependency Management

By default, Travis CI will run

$ npm install

to install your dependencies.

Default Test Script

For projects using npm, Travis CI will execute

$ npm test

to run your test suite.

Links

• Building a Node.js project, by Travis CI
• Customizing the Build, by Travis CI
• CI-By-Example, by bevacqua
• Travis-CI: What, Why, How, by Sayanee Basu

github-upload's Issues

A few parting words

Nice Work

Congratulations @danxi, you've completed this course! 🎉

What went well

Before I say good-bye, I want to recap all the tasks you've accomplished. You:

• Learned what to do with an empty repo on GitHub ✨
• Created a .gitignore and removed bulky binaries
• Used your favorite local tools to push existing code
• Set your code up in a GitHub repository 🎆

What's Next?

Now that you've moved your Git repository to GitHub, managing your repository and adding collaborators are common next steps. Here are some recommended courses we think you might be interested in:

Community Starter Kit
Hosting a project on GitHub enables you to share your work with millions of other developers. This course will walk you through the different items you can add to your repository to welcome new contributors and make it easier for them to report issues, suggest new features, or potentially submit a pull request!

Create a release based workflow
Now that you have a repository on GitHub learn how to utilize a release workflow to create new releases for your project through an efficient development workflow.

There's so much more you can do with GitHub, and you have a solid start. Now...what will you learn next?

---

I won't respond to this issue, just close it when you are done!

Planning the upload to GitHub

Step 1: Planning the move

Uploading your project to GitHub gives you the feature-rich tools and collaboration needed to elevate your project to the next level. Not to mention, it's also pretty exciting. If you're doing this for the first time, you have a few options when uploading your project to GitHub. This course will guide you through the necessary steps to upload a local project to be hosted on GitHub.

I know some people like to get straight to the point while others like more information. For those who like more information, be sure to check out the drop-downs like this one ⬇️

Why move to GitHub?

---

Why move to GitHub?

You may be wondering what this GitHub thing is all about and why you should use it. If this sounds like you, here are a few reasons to make GitHub your project's new home:

• Version control — Everything on GitHub is stored in Git, the best version control system around. Version control allows you to experiment and make mistakes in code without messing up your final product.
• Keep your code in one place — Whether you work on multiple computers or just want to get some important projects off your computer, GitHub is the perfect place to store your projects online.
• Collaboration — Once your code is on GitHub, you can invite others to work on your code with you, share it with the world, or send a link to a friend to help you debug a problem.

---

Where is your project?

Most users find it is easiest to upload a project that is already located on their local machine, so the goal of this first step is to make a local copy of the repository. First, let's make sure this course is going to give you the right steps:

Is your project on another version control system, such as Mercurial, Subversion, or another Git platform?

---

Moving your project from another version control system

If you are moving your project from another version control system, the steps are a bit different that uploading your project from your local machine. Because of this, we have a dedicated course for migrating your project to GitHub.

If you are moving your project from Mercurial, Subversion, or another Git platform, join the Migrating your project to GitHub course to migrate your project to GitHub.

---

Is your project using version control?

---

Is your project using version control

If you aren't sure whether or not your code is under version control, it probably isn't. However, here are a few tests you can apply to know for certain:

• Can you view a history of the changes you have made?
• Can you easily roll back to a previous version of your project?
• Are you required to provide "messages" or "commits" when you make changes?

If none of these are true, your project isn't using version control.

---

⌨️ Activity: Exporting your project

Choose the drop-down below that best fits your current situation or for a printable version of the steps in this course, check out the Quick Reference Guide.

Your project is already on your local machine

---

Your project is already on your local machine

✨ Terrific! @danxi since you already have the project locally, you are almost ready to move it to GitHub.

To confirm: You have a project directory on your computer and you want to save it on GitHub.

• If this is correct, close this issue to signal you are finished with this step. I will open a new issue to show you how to optimize your repository for Git operations.

• If this is incorrect, please use the next drop-down to learn how to export your project to your local machine or join the Migrating your project to GitHub course to migrate your project to GitHub.

---

Your project is on a non-version controlled site, such as CodePen or Glitch

---

General instructions

There are many platforms that allow users to create and store projects. We can't cover them all, but we will do our best to cover the more common examples. First, let's cover general instructions:

• Export your project using the tools available on the current site. This will usually happen via a .zip, or some other compressed format, downloaded directly to your local machine
• Save the .zip file
• Extract the .zip file

Now let's talk about specific platforms:

Exporting from CodePen

From the main page of your CodePen project:

1. Click the Export button in the bottom right corner
2. Save the exported .zip file in your local directory
3. Extract the .zip file

Exporting from Glitch

From your Glitch project page:

1. Click the dropdown next to your project name in the top right corner
2. Select Advanced Options
3. Select Download Project
4. Save the exported file in your local directory
5. Extract the file
6. Rename the app folder as desired

---

Ready to move on?

Close this issue to signal you are finished with this step. I will open a new issue to show you how to optimize your repository for Git operations. 🎉

---

Watch below for my response

🤖 I'm waiting for you to close the issue before moving on.

Sometimes I respond too fast for the page to update! If you perform an expected action and don't see a response from me, wait a few seconds and refresh the page for your next steps.

Public or private repository?

Step 4: Private or Public?

Right now, your repository is set to public.

You can change the visibility of a repository to Private or Public at any time in your repository's Settings tab, but there are some things you should know.

Private Repositories

If your repository is private, the only people who can see your code are you and the collaborators ^📖 you've invited.

There is a small charge associated with Private repositories, but if your project has sensitive information, it's worth it.

Public Repositories

In public repositories, anybody can see your code. Millions of open source repositories on GitHub are public, too!

Licenses, code of conduct, and other files are important when you create a public repository. There are many benefits to this, but it's also a large responsibility. Keep in mind that once a repository is public and open source, there are certain implications about keeping it public, depending on the license chosen.

It's important to note that public does not equal open source! The license associated with code determines whether or not it is open source.

---

Watch below for my response!

🤖 I'm waiting for you to close this issue.

Uploading your project

Step 3: Make the move

Having a project already stored locally enables you to move it to GitHub rather quickly. The following activity provides instructions to move your local project to GitHub using various tools. Select the tool you are most comfortable with and get importing 😄.

⌨️ Activity: Moving your local project

1. In the Code tab of this repository, copy the URL shown under Quick Setup.
2. Follow the instructions below based on what tool you'd like to use locally.

Using the command line

---

Using the command line

1. In your command line, navigate to your project directory. Type git init to initialize the directory as a Git repository.
2. Type git remote add origin https://github.com/danxi/github-upload.git
3. Type git add .
4. Type git commit -m "initializing repository"
5. Type git push -u origin master to push the files you have locally to the remote on GitHub. (You may be asked to log in.)

---

Using GitHub Desktop

---

Using GitHub Desktop

1. In GitHub Desktop, add a local repository by clicking File > Add a Local Repository, and then navigating to your local repository.
2. Create your first commit by typing a summary commit message in the field provided and clicking Commit to master
3. Add the remote by clicking Repository > Repository Settings... and pasting the URL from your repository on GitHub into the "Primary remote repository (origin)" field. Click Save.
4. Click Publish in the top right corner to push your repository to GitHub.

---

Using Visual Studio Code

---

Using Visual Studio Code

1. In Visual Studio Code, open the folder for your project.
2. Click the icon on the left for Source Control.
3. On the top of the Source Control panel, click the Git icon.
4. If the files you see match the repository you want to create, click Initialize Repository.
5. Next to the word CHANGES, click the symbol of the plus sign to stage all of the changes.
   • This is part of the two stage commit. You can use this staging function to create meaningful commits throughout the development process.
6. In the box in the Source Control panel, type a commit message. Something like "initial commit - moving project" could work.
7. Click the checkmark at the top of the Source Control panel.
8. Open the integrated terminal found under View > Integrated Terminal.
9. In your command line, type git remote add origin
10. In the Source Control Panel, click the expandable three dots that open a menu of options.
11. When asked if you'd like to publish the branch, click Okay.

---

Using Atom

---

Using Atom

1. In Atom, open the folder for your project
2. At the top of your screen, click Packages. Select GitHub, and then toggle the Git Tab from the drop-down menu.
3. Select Create Repository within the Git tab on the right-hand size of your screen.
4. Select Init to accept the default prompt of the pop up window
5. In the Git tab, you can see that your files are ready for staging. It should be accounted for, but double check to make sure that none of your binaries or files that you listed in the .gitignore are listed in this dialog menu.
   - If they are, double check your .gitignore file to make sure they're included or remove them from your directory.
6. Select Stage All
   - This is part of the two stage commit. You can use this staging function to create meaningful commits throughout the development process.
7. In the box at the bottom of the Git panel, type a commit message. Something like "initial commit - moving project" could work.
8. Select Commit
9. Close Atom
10. In your command line, navigate to your project directory.
11. Type git remote add origin
12. Return to Atom, and select the Up/Down arrow icon at the bottom of your Git Tab
13. Click Push, above the noted dialog.
14. Return to your repository, and note a successful push by finding your files on GitHub's code tab.

---

Using Eclipse

---

Using Eclipse

1. In Eclipse, from the Eclipse Marketplace, install the eGit GitHub plugin.
2. Open your existing project.
3. Display the Git Repositories window by selecting Window > Show View > Other > Git > Git Repositories.
4. Click the Create a Git Repository button on the Git Repositories pane.
5. Make changes to your project and create a commit.
6. Push the master branch.
7. When asked for a remote, paste the URL you copied earlier.
8. Click next, and enter the branch name.

---

---

Watch below for my response

🤖 Once you push your project to GitHub, I'll provide the next steps in your journey.

Preparing the project for Git

Step 2: Prepare the project

Working with Binary files

In general, there are two types of files: text files and binary files.

Text files, like most code files, are easily tracked with Git ^📖 and are very lightweight.

However, binary files like spreadsheets, presentations with slides, and videos don't work well with Git. If your repository already has some of these files, it's best to have a plan in place before you enable Git version control.

You could choose to remove the binary files, or use another tool like git-lfs (Git Large File Storage). We won't get into detail on how to set up git-lfs in this course, but we will talk about .gitignore files next, which are key to protecting your code from becoming bloated with binaries.

Add a .gitignore

As we convert your project to a Git repository, it should only include the source code necessary to build or compile your project. In addition to avoiding binaries as we discussed above, you will also want to keep build artifacts out of your version controlled code.

To do this, you will create a file in your current project named .gitignore. Git will use the .gitignore to determine which files and directories should not be tracked under version control. The .gitignore file is stored in your repository in order to share the ignore rules with any other users that interact with the repository.

Since the files to be ignored are dependent on the language you are using, the open source community has contributed some great templates for .gitignore files in the github/gitignore repository.

⌨️ Activity: Prepare your repository

1. Remove any binary files from your repository.
2. In your local environment, create a .gitignore file. You can use a template or create your own.

When you are finished, close this issue. I will open a new issue with the next steps. 🎉

---

Watch below for my response

🤖 I'm waiting for you to close this issue before moving on.