The following recipes will be covered in this chapter:

• Introducing VCS and Git
• Introducing AWS CodeCommit - Amazon managed SAAS Git
• Getting started with CodeCommit for HTTP users
• Setting up CodeCommit for SSH users using AWS CLI
• Applying security and restrictions
• Migrating a Git repository to AWS CodeCommit

In this chapter, we will be working with Git and will mostly play around with AWS CodeCommit. We will set up a repository in AWS CodeCommit using the console, as well as CLI, and enforce a security policy on top of it. We will also migrate the basic Git-based repository to AWS CodeCommit, and will cover some best practices and troubleshooting while dealing with issues on AWS CodeCommit.

VCS comes under the category of software development, which helps a software team manage changes to source code over time. A VCS keeps track of each and every modification to the code in a database. If a mistake is made, the developer can compare earlier versions of the code and fix the mistake while minimizing disturbance to the rest of the team members.

The most widely used VCS in the world is Git. It's a mature and actively maintained open source project developed by Linus Torvalds in 2005.

A version control system (VCS) is the system where the changes to a file (or a set of files) usually get recorded so that we can recall it whenever we want. In this book, we mostly play around with the source code of software or applications, but that does not mean that we can track the version changes to only the source code. If you are a graphic designer or infrastructure automation worker and want to keep every version of image layout or configuration file change, then VCS is the best thing to use.

There are lots of benefits to using VCS for a project. A few of them are mentioned here:

• Collaboration: Anyone or everyone in the team can work on any file of the project at any time. There would be no question where the latest version of a file or the whole project is. It's in a common, central place, your version control system.
• Storing versions properly: Saving a version of a file or an entire project after making changes is an essential habit, but without using a VCS, it will become very tough, tedious, and error-prone. With a VCS, we can save the entire project and mention the name of the versions as well. We can also mention the details of the projects, and what all changes have been done in the current version as compared to the previous version in a README file.
• Restoring previous versions: If you mess up with your present code, you can simply undo the changes in a few minutes.

There are many more features of using VCS while implementing or developing a project.

The types of VCS are mentioned as follows:

• Local version control system: In a local VCS, all the changes to a file are kept in the local machine, which has a database that has all the changes to a file under revision control, for example, Revision control system (RCS).
• Centralized version control system: In a centralized VCS, we can collaborate with other developers on different machines. So in these VCS, we need a single server that contains all the versioned files and the number of clients can check out files from that single server, for example, Subversion (SVN).
• Distributed version control system: In a distributed VCS, the client not only checks out the latest version of the file but also mirrors the whole repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back to the server to restore it. An example of this is Git.

Git is a distributed VCS, and it came into the picture when there was some maintenance needed in the Linux Kernel. The Linux Kernel development community was using a proprietary Distributed version control system (DVCS) called BitKeeper. But after some time, the relationship between the Linux community developers and the proprietary software BitKeeper broke down, which led to Linux community developers (in particular Linux creator Linus Torvalds) developing their own DVCS tool called Git. They took a radical approach that makes it different from other VCSs such as CVS and SVN.

It wouldn't be appropriate to say Git is better than SVN or any other VCS. It depends on the scenario and the requirements of the project. But nowadays, most enterprises have chosen Git as their VCS for the following reasons:

• Distributed nature: Git has been designed as a distributed VCS, which means every user can have a complete copy of the repository data stored locally, so they can access the file history extremely fast. It also allows full functionality when the user is not connected to the network, whereas in a centralized VCS, such as SVN, only the central repository has the complete history. This means the user needs to connect with the network to access the history from the central repository.
• Branch handling: This is one of the major differences. Git has built-in support for branches and strongly encourages developers to use them, whereas SVN can also have branches, but its practice and workflow does not have the inside command. In Git, we can have multiple branches of a repository, and in each repository, you can carry out development, test it, and then merge, and it's in a tree fashion. In SVN, everything is linear; whenever you add, delete, or modify any file, the revision will just increment by one. Even if you roll back some changes in SVN, it will be considered a new revision:
  
• Smaller space requirements: Git repositories and working directory sizes are very small in comparison with SVN.

The following are some of the features of Git:

• Captures snapshots, not entire files: Git and other VCSs had this major difference; VCS keeps the record of revisions in the form of a file. This means it keeps a set of files for every revision. Git, however, has another way of accounting for changes. Every time you commit or save the state of your project in Git, it basically takes a snapshot of what your files look like at that very moment and stores a reference to that snapshot. If files have not been changed, Git does not store the file again; it stores a link to the previous identical file it has already stored.
• Data integrity: Before storing any data in a Git repository, it is first checksummed, and is then referred to by that checksum. That means, if you carry out any other modification in the file, then Git will have every record of every modification. The mechanism used by Git for checksumming is known as SHA-1 hash.

  SHA-1 hash looks something like this:

  b52af1db10a8c915cfbb9c1a6c9679dc47052e34

• States and areas: Git has three main states and views all files in three different states:

  • Modified: This is the modification that has been done in the file, but not yet written or committed in the database.
  • Committed: This ensures that the source code and related data are safely stored in your local database or machine
  • Staged: This ensures that the modified file is added in its current version and is ready for the next commitment.

Here are the steps and commands that will guide you through installing and setting up Git and creating a repository in a very famous self-hosted Git, GitHub.

1. If you want to use Git, we have to install the Git package on our system:
   • For Fedora distributions (RHEL/CentOS):

# yum install git

• For Debian distributions (Debian/Ubuntu):

# apt-get install git

2. Configure your identity with Git because every Git commit uses this information, for example, the following commit has been done by User awsstar and email is awsstar@foo.com:

# git config --global user.name “awsstar”
# git config --global user.email “awsstar@foo.com”

3. Check your settings. You will find the above username and email-id:

# git config --list

4. Now, let's try to create a repository on GitHub:
   • Hit www.github.com in your web browser and log in with your credentials
   • Click on create New Repository

Then, we will get something like the following screenshot. We have to mention the Repository name and a Description of the repository. After that, we need to select Public or Private based on our requirements. When we opt for Public, then anyone can see your repository, but you pick who can commit; when you opt for Private, then you pick who can see and who can commit, meaning by default it won't be visible to anyone. After that, we have to initialize the README, where we can give a detailed description of the project and click on Create Repository:

5. Once we have a repository, HelloWorld, then let's try to clone it to our local machine and some program files. Cloning a repository means creating a local copy of the repository and it can be done as follows:
   • Fetch the Git URL by clicking on Clone or Download (https://github.com/awsstar/HelloWorld.git):

• • Now, clone the URL:

    root@awsstar:~# git clone https://github.com/awsstar/HelloWorld.git
     Cloning into 'HelloWorld'...
     remote: Counting objects: 4, done.
     remote: Compressing objects: 100% (3/3), done.
     remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
     Unpacking objects: 100% (4/4), done.
     Checking connectivity... done.
     root@abae81a80866:~# ls
     HelloWorld
     root@awsstar:~# cd HelloWorld
     root@awsstar:~/HelloWorld# ls
     LICENSE README.md
     root@awsstar:~/HelloWorld#

6. We have the HelloWorld repository on our local machine. So, let's add index.html and push it back to the repository. Create a file, index.html, and write HelloWorld inside it:

    root@awsstar:~/HelloWorld# echo '<h1> HelloWorld </h1>' > index.html

7. The git status command checks the current status and reports whether there is anything left to commit or not:

    root@awsstar:~/HelloWorld# git status
    On branch masterYour branch is up-to-date with     'origin/master'.Untracked files: (use "git add <file>..." to include     in what will be committed)
     index.html
     nothing added to commit but untracked files present (use "git add"     to track)

8. Now to add the changes to the repository, we have to enter this command:

    root@awsstar:~/HelloWorld# git add .

9. To store the current contents of the index in a new commit, along with a log message from the user describing the changes, we need to enter this command:

    root@awsstar:~/HelloWorld# git commit -m "index.html added"
    [master 7be5f57] index.html added 1 file changed, 1 insertion(+)
    create mode 100644 index.html

10. Push your local changes to the remote repository:

    root@awsstar:~/HelloWorld# git push origin master
     Username for 'https://github.com': awsstar
     Password for 'https://awsstar@github.com':
     Counting objects: 3, done.
     Delta compression using up to 4 threads.
     Compressing objects: 100% (2/2), done.
     Writing objects: 100% (3/3), 327 bytes | 0 bytes/s, done.
     Total 3 (delta 0), reused 0 (delta 0)
     To https://github.com/awsstar/HelloWorld.git
     a0a82b2..7be5f57 master -> master

Here, we can see that index.html is now in our GitHub repository:

AWS CodeCommit is a version control system, which is managed by Amazon Web Services, where we can privately store and manage assets in the Cloud and integrate with AWS. It is a highly scalable and secure VCS that hosts private Git repositories and supports the standard functionality of Git, so it works very well with your existing Git-based tools.

The following are the benefits of CodeCommit:

• Managed service: CodeCommit is fully managed, distributed, fault tolerant, and carries no administrative overhead. It is elastic (able to adapt to a high workload) and, as mentioned, integrated with other AWS services.
• No limit to storage and file type: We can store as many files as we want, because CodeCommit does not have space limitations. We can store not only source code but also documents and binary files.
• Data and access security: CodeCommit repositories are encrypted while they are in AWS CodeCommit or when getting cloned somewhere. It is also integrated with IAM for user-level or specific API-level security.
• HA (high availability): Whatever data we push into the repository, it will replicate across AZs (Availability Zones).
• Easy migration of Git-based repository: We can easily migrate a remote Git-based repository to AWS CodeCommit.

These are some limitations or drawbacks of self-hosted VCS (BitBucket/GitHub/GitLab), which you won't find in AWS CodeCommit:

• We may have to pay a license fee on a per-developer basis
• We may end up with high hardware maintenance costs and high support staffing costs
• Limitation on the amount and types of files that can be stored and managed
• Limitation on the number of branches, the amount of version history, and other related metadata that can be stored

AWS CodeCommit is configured just like other Git-based repositories, such as GitHub. The following diagram shows how we use a development machine, AWS CLI/AWS Console, and CodeCommit to create and manage a repository:

The basic workflow is described as follows:

1. Using AWS CLI or CodeCommit Console, we can create a CodeCommit repository.
2. Post that, use git clone in the CodeCommit repository URL on your local development machine.
3. Once the repository gets cloned into the development machine, make the changes in the repository by adding to or editing the files. After that, enter the git add command and put it into the staging area, commit by giving a change message, and then push it back to the repository.
4. After that, we can carry out git pull to synchronize the code in the AWS CodeCommit repository with our local repository. At this point in time, you will be working with the latest changes and the versions of the files.

AWS provides both Console and CLI access to create a repository in AWS CodeCommit. Let's get started and create a repository, then clone it in development using HTTPS credentials.

1. Open the AWS CodeCommit console at https://console.aws.amazon.com/codecommit.

2. On the welcome page, choose Get Started Now (if a dashboard page appears instead of the welcome page, choose Create repository):

3. Then, we will get a box, Connect to your Repository, which will provide further instructions on ways of connecting to CodeCommit via HTTPS or SSH. We can close that and move further, but it's advisable to read every message or information prompt from AWS.

4. Now, we will clone the repository, but before that, we need HTTPS Git credentials. We will get the HTTPS Git credentials of an IAM user, which is attached with the policy of CodeCommit access through IAM console. So let's try to create a user first, assign the CodeCommit policy, and get the HTTPS Git credentials for that user.
5. Open the AWS IAM console by hitting https://console.aws.amazon.com/iam in a new tab.
6. Click on Add User.
7. Give IAM user a username as awsccuser and check both the Access type boxes (Programmatic access /AWS Management Console access), set a Custom password, and click on Next:Permission:

8. We then get the set permission on the username page. On this page, first click on Attach existing Policies directly after which we search CodeCommit in the search box of Policy type:

9. Click on the AWSCodeCommitPowerUser policy and click on Next.
10. Post review, click on Create User.
11. Download credentials provided by the AWS IAM user; these credentials are basically secret and access key.
12. After that, we need to click on the User section. Then, click on Security credentials.

13. Scroll down and we will see a section called HTTPS Git credentials for AWS CodeCommit; after that, click on Generate:
    
    
14. Once we click on Generate, we will get a username and password; then, click on Download credentials.
15. Again, let's go to the CodeCommit console and click on Clone URL and then HTTPS.
16. Copy the link and enter the following command on the development machine:

    # git clone https://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld

    root@awsstar:~# git clone https://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld
     Cloning into 'HelloWorld'...
     Username for 'https://git-codecommit.us-east-1.amazonaws.com':     awsccuser-at-160384169139
     Password for 'https://awsccuser-at-160384169139@git-    codecommit.us-    east-1.amazonaws.com':
     warning: You appear to have cloned an empty repository.
     Checking connectivity... done.
     root@awsstar:~# ls
     HelloWorld
     root@awsstar:~#

17. We just cloned an empty repository; now, it's time to put a sample index.html file in the CodeCommit HelloWorld repository. We will now create a file named index.html and put some content in it. Add content and commit it, before pushing it to the repository:

     root@awsstar:~# cd HelloWorld/
     root@awsstar:~/HelloWorld# echo '<h1> Hello World </h1>' >             index.html
     root@awsstar:~/HelloWorld# git add .
     root@awsstar:~/HelloWorld# git commit -m " index.html push "
     [master (root-commit) bc76f76] index.html push
     1 file changed, 1 insertion(+)
     create mode 100644 index.html
     root@awsstar:~/HelloWorld# git push origin master
     Username for 'https://git-codecommit.us-east-1.amazonaws.com':         awsccuser-at-160384169139
     Password for 'https://awsccuser-at-160384169139@git-        codecommit.us-    east-1.amazonaws.com':
     Counting objects: 3, done.
     Writing objects: 100% (3/3), 233 bytes | 0 bytes/s, done.
     Total 3 (delta 0), reused 0 (delta 0)
     To https://git-codecommit.us-east-            1.amazonaws.com/v1/repos/HelloWorld
     * [new branch] master -> master

18. Now, we pushed a file to our newly created repository in AWS CodeCommit. To verify this, let's see the AWS CodeCommit console, and see whether the checked-in file is there or not (refresh the CodeCommit console, if you were there from the start):

19. To see more details, click on Commits, and see which user has committed and which files have changed:

20. This shows information such as when index.html got pushed, on what date, and by whom.

21. Now, to wrap up or to delete the repository, click on the Settings section and on the Delete Repository; then a prompt box will pop up, where we put the repository name and click on Delete:

22. After clicking on Delete, your repository will get deleted:

In the previous recipe, we saw how we can access the repository using the username and password. In this section, we will use SSH private and public keys to access the repository. We will be accessing the repository using SSH connections.

This topic assumes that you already have, or know how to create, a pair of public/private keys. You should be familiar with SSH and its configuration files.

Before setting up CodeCommit for SSH users, we need the AWS CLI installed and configured with the respective AWS account. To install the AWS CLI on our development machine, we need to perform these steps:

1. We need to install python-pip and AWS CLI tools. Usually, in CentOS/RHEL, python-pip comes with EPEL (Extra Package for Enterprise Linux):

    # yum install epel-release python-pip
    # pip install awscli

2. Once we have the awscli command installed in our system, we have to configure it using the access and secret Key, as well as the region we will use the AWS account in. If you remember, we had created a user while generating the https git credentials, but at that moment, we also downloaded another type of credentials, the secret and access key. So, we need that over here.
3. Now, let's configure AWS CLI:

    awsstar@awsstar:~$ aws configure
     AWS Access Key ID [None]: AKIxxxxxxxxxxxxxDDA
     AWS Secret Access Key [None]: b+GEuc2u3xxxxxxxxxxxxxx+av/5eK
     Default region name [None]: us-east-1
     Default output format [None]:

4. Once the configuration is done, let's try to list the repository:

    awsstar@awsstar:~$ aws codecommit list-repositories
     {
     "repositories": [
     {
     "repositoryName": "NixSrj",
     "repositoryId": "73caf1e3-65a9-44bf-8c6a-a3bd3e0260b0"
     },
     {
     "repositoryName": "ECS-POC",
     "repositoryId": "62063220-b0fc-4519-9d54-896be46a7521"
     },
     {
     "repositoryName": "terraform-Openshift",
     "repositoryId": "20f88492-81bb-4068-8867-5d17a1d3ec5b"
     }
     ]
     }

5. So it's showing the repository, which means the credentials are working fine and we are good to go to create a repository now.

1. Create a repository, HelloWorld:

    awsstar@awsstar:~$ aws codecommit create-repository --repository-    name HelloWorld --repository-description "This repository includes     static page of HelloWorld"
     {
     "repositoryMetadata": {
     "repositoryName": "HelloWorld",
     "cloneUrlSsh": "ssh://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld",
 "lastModifiedDate": 1501778613.664,
 "repositoryDescription": "This repository includes static page of     HelloWorld",
 "cloneUrlHttp": "https://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld",
 "creationDate": 1501778613.664,
 "repositoryId": "53866a81-8576-4e79-ab5a-36882c33b717",
 "Arn": "arn:aws:codecommit:us-east-1:160384169139:HelloWorld",
 "accountId": "160384169139"
 }
 }

2. Now, check it using the following command:

    awsstar@awsstar:~$ aws codecommit list-repositories
     {
     "repositories": [
     {
     "repositoryName": "HelloWorld",
     "repositoryId": "53866a81-8576-4e79-ab5a-36882c33b717"
     }
     ]
 }    

3. Let's try to clone the HelloWorld repository from CodeCommit to our development machine; but before that, we have to establish SSH authentication. To do that, we have to perform the following operations to generate the SSH keys:

    awsstar@awsstar:~$ ssh-keygen
     Generating public/private rsa key pair.
     Enter file in which to save the key (/home/awsstar/.ssh/id_rsa):
     Created directory '/home/awsstar/.ssh'.
     Enter passphrase (empty for no passphrase):
     Enter same passphrase again:
     Your identification has been saved in /home/awsstar/.ssh/id_rsa.
     Your public key has been saved in /home/awsstar/.ssh/id_rsa.pub.
     The key fingerprint is:
     SHA256:NMUiRSDRD9SxrSIcYm9A4BYau2TOaeEfk5TgRmy3i4o     root@aa21529d724f
     The key's randomart image is:
     +---[RSA 2048]----+
     |+=. o+o=+o. |
     |=*o...+ o+. |
     |+O=oo ++.. |
     |Oo+*.. ..o |
     |.*.+* . S |
     |...oo. . |
     |o . |
     |E |
     | |
     +----[SHA256]-----+

4. The preceding command will create two keys; one is the public key (id_rsa.pub) and the other one is the private key (id_rsa).
5. Now, we have to upload the public key to the user of AWS we created:

    awsstar@awsstar:~$ cd .ssh
    awsstar@awsstar:~/.ssh$ aws iam upload-ssh-public-key --user-name     awsccuser --ssh-public-key-body "ssh-rsa     AAAAB3NzaC1yc2EAAAADAQABAAABAQCk437p8/JmhGOdM9oYNK/r1xpOnuA2cQNfYys7lnE9gXJdTEjniHNFcJZMkIVmtYQGAqEh37BWGfXl4s5iw/NSfkDuZf8zegAgyPryR0KTTUG2f/rrtyLtlAPlSXjtCmHakZzhwIoRJtzkDbSpKoUOD8fNnS3kKIwk7Dp3+gGLLgo9eoZdud9h/E5+NpORog7wg7xaTgg3mwa9StaPHKMxJNwNc71dIuUyAh2S6bDbHB3QWLNfrJABYqPq5HGFh3KLogH9GHBMajshLEOS4Ygk3uC8FzB+eP4oneuWd2n68N3qg5RmX0U5lAL8s3+ppuhmjlbSvDOdBUJdpgEL/AQZ awsstar@awsstar"

6. We need to make a note of some details, such as the SSHPublicKeyId provided as output in thew JSON format, while uploading the SSH public key.
7. We have to bring about some modification in the config file lying in $HOME/.ssh/config:

    awsstar@awsstar:~$ vi .ssh/config
    Host git-codecommit.us-east-1.amazonaws.com
    User APKAIGJDPRJL3INHSJ6Q
    IdentityFile ~/.ssh/id_rsa

8. Once we are done saving the config file, let's see the connectivity between the development machine and AWS CodeCommit:

    awsstar@awsstar:~$ ssh git-codecommit.us-east-1.amazonaws.com
     The authenticity of host 'git-codecommit.us-east-1.amazonaws.com     (54.239.20.155)' can't be established.
     RSA key fingerprint is     SHA256:eLMY1j0DKA4uvDZcl/KgtIayZANwX6t8+8isPtotBoY.
     Are you sure you want to continue connecting (yes/no)? yes
     Warning: Permanently added 'git-codecommit.us-east-    1.amazonaws.com,54.239.20.155' (RSA) to the list of known hosts.
     You have successfully authenticated over SSH. You can use Git to     interact with AWS CodeCommit. Interactive shells are not     supported.Connection to git-codecommit.us-east-1.amazonaws.com closed     by remote host.
     Connection to git-codecommit.us-east-1.amazonaws.com closed.

9. We get the output that says Successfully authenticated over SSH, so now we are ready to clone the repository. We can clone the SSH URL of the repository, which we obtain from the JSON output while creating the repository:

    awsstar@awsstar:~$ git clone ssh://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld
     Cloning into 'HelloWorld'...
     warning: You appear to have cloned an empty repository.
     checking connectivity... done
    awsstar@awsstar:~$ ls
    HelloWorld
    awsstar@awsstar:~$

10. So, we cloned an empty repository; now it's time to put a sample index.html file in the CodeCommit HelloWorld repository:

     awsstar@awsstar:~/HelloWorld$ echo '<h1> Hello World </h1>' >     index.html
     awsstar@awsstar:~/HelloWorld$ git add .
     awsstar@awsstar:~/HelloWorld$ git commit -m " index.html push "
     [master (root-commit) bc76f76] index.html push
     1 file changed, 1 insertion(+)
     create mode 100644 index.html
     root@awsstar:~/HelloWorld# git push origin master
     Counting objects: 3, done.
     Writing objects: 100% (3/3), 233 bytes | 0 bytes/s, done.
     Total 3 (delta 0), reused 0 (delta 0)
     To ssh://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld
     * [new branch] master -> master

11. In this stage, we successfully pushed our local file into the AWS CodeCommit HelloWorld repository.

In an enterprise where a product is being developed, we find lots of developers on different teams working with different repositories but in the same Git-based VCS.

Here in CodeCommit, if we give a user CodeCommitPowerUser access, then the user will have full control over all the repositories, except the deletion of repositories. So, a Power User will be able to see the source code of all other repositories, that is, there won't be any privacy. This is the kind of permission you should avoid giving another user.

In some companies, they have different use cases, for example, they only require a few of their developers to have access to all Git-based commands and on the specific repository. We dive into how to implement this type of scenario.

To implement this scenario, we use AWS IAM services, where we will create a user and attach it to a CodeCommit custom policy, and that policy will have access to only a specific repository with specific Git commands.

Let's get started with that, and perform the following operations:

1. First of all, let's create a custom policy where we will give the restriction definition.
2. Go to IAM Console and click on the Policies section. Then, click on Create Policy:
   
3. Click on Create Your Own Policy:

4. You will be redirected to another page where you have to fill in the Policy Name, a description of the policy, and a policy document. The policy document will be the definition, where we will mention the resources and actions:

5. Insert the following policy definition (x60xxxxxxx39 will be basically your account ID):

    {
     "Version": "2012-10-17",
     "Statement": [
     {
     "Effect": "Allow",
     "Action": [
     "codecommit:GitPull",
     "codecommit:GitPush"
     ],
     "Resource": "arn:aws:codecommit:us-east-1:x60xxxxxxx39:HelloWorld"
     }
     ]
     }

6. Click on Create Policy; then we will have our own custom policy:
   
7. Now, let's remove the AWSCodeCommitPowerUser access from the IAM user that we created to clone the repository by clicking on x:

8. Click on Add permissions, after that click on Attach Existing Policies Directly and search for Policy name in filter, check that, and save it:

9. We will have a user with only our custom policy, which means the user will only have access to the HelloWorld repository and only two actions, git push and git clone:

    awsstar@awsstar:~$ aws codecommit list-repositories
    An error occurred (AccessDeniedException) when calling the     ListRepositories operation: User:     arn:aws:iam::16xxxxxx139:user/awsccuser is not authorized to perform:     codecommit:ListRepositories

The preceding command output shows AccessDeniedException, that is, awsccuser is not authorized to perform codecommit:ListRepositories. The reason for this is we have given access to only two operations or actions: git push and git clone.

As a developer, it's highly possible that we have our code in a GitHub account. So, we will see the migration of a GitHub repository to AWS CodeCommit. Customers often need to replicate commits from one repository to another to support disaster recovery or cross-region CI/CD pipelines. AWS CodeCommit has lots of flexibility when it comes to AWS developer services, such as CodeBuild, CodeDeploy, and CodeStar. Most companies nowadays will think to migrate from those repositories to AWS CodeCommit:

The following are the steps for migrating a project or repository hosted on another Git repository to AWS CodeCommit:

1. Firstly, we have to create a CodeCommit repository named HelloWorld (refer to the previous CodeCommit repository either using HTTPS or SSH).

2. After creating a CodeCommit repository, clone it to the local machine. Since we are cloning the repository using an HTTPS connection, then we need to give the HTTPS credentials of username and password (you can refer to the previous recipe):

    root@awsstar:~# git clone https://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld
     Cloning into 'HelloWorld'...
     Username for 'https://git-codecommit.us-east-1.amazonaws.com':     awsccuser-at-1xxxxxxxx39
     Password for 'https://awsccuser-at-16xxxxxxx39@git-codecommit.us-    east-1.amazonaws.com':
     warning: You appear to have cloned an empty repository.
     Checking connectivity... done.

3. Now, clone a GitHub repository using --mirror into another new folder. Here we have a GitHub repository whose name is Docker-Compose-CI-CD, which will be cloned into a pre-existing empty folder precommit:

>

     root@awsstar:~# mkdir precommit
     root@awsstar:~# git clone --mirror      https://github.com/awsstar/Docker-Compose-CI-CD.git precommit
     Cloning into bare repository 'precommit'...
     remote: Counting objects: 36, done.
     remote: Total 36 (delta 0), reused 0 (delta 0), pack-reused 36
     Unpacking objects: 100% (36/36), done.
     Checking connectivity... done.

4. Go to the directory where you made the clone:

    root@awsstar:~# cd precommit/

5. Run the git push command, specifying the URL and name of the destination AWS CodeCommit repository and the --all option:

    root@awsstar:~/precommit# git push https://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld --all
     Username for 'https://git-codecommit.us-east-1.amazonaws.com':     awsccuser-at-160384169139
     Password for 'https://awsccuser-at-160384169139@git-    codecommit.us-    east-1.amazonaws.com':
 Counting objects: 36, done.
     Delta compression using up to 4 threads.
     Compressing objects: 100% (33/33), done.
     Writing objects: 100% (36/36), 3.73 KiB | 0 bytes/s, done.
     Total 36 (delta 17), reused 0 (delta 0)
     To https://git-codecommit.us-east-    1.amazonaws.com/v1/repos/HelloWorld
     * [new branch] master -> master

6. Now, let's view the migrated files in AWS CodeCommit:

Here, we can see how easily we have migrated the project from GitHub to AWS CodeCommit.