diff --git a/.github/workflows/dev.yaml b/.github/workflows/dev.yaml index ee4becb..49bf4bb 100644 --- a/.github/workflows/dev.yaml +++ b/.github/workflows/dev.yaml @@ -18,4 +18,4 @@ jobs: - uses: actions/checkout@v3 - name: Deploy run: | - echo deploying into Dev env \ No newline at end of file + echo deploying into Dev env diff --git a/.github/workflows/pre-submit-test.yaml b/.github/workflows/pre-submit-test.yaml index d0ca1fb..1322070 100644 --- a/.github/workflows/pre-submit-test.yaml +++ b/.github/workflows/pre-submit-test.yaml @@ -11,7 +11,7 @@ jobs: runs-on: ubuntu-latest steps: - name: clone - run: | + run: | git clone https://github.com/${{ github.event.pull_request.head.repo.full_name }} tmprepo - name: test branches question run: | @@ -36,5 +36,3 @@ jobs: git checkout main cd test bash merge_repos.sh - - diff --git a/.github/workflows/prod.yaml b/.github/workflows/prod.yaml index bd34634..7f24186 100644 --- a/.github/workflows/prod.yaml +++ b/.github/workflows/prod.yaml @@ -19,4 +19,4 @@ jobs: - uses: actions/checkout@v3 - name: Deploy run: | - echo deploying into Test env \ No newline at end of file + echo deploying into Test env diff --git a/.github/workflows/test.yaml b/.github/workflows/test.yaml index 0db1153..d75e1d2 100644 --- a/.github/workflows/test.yaml +++ b/.github/workflows/test.yaml @@ -11,7 +11,7 @@ jobs: - name: Check version run : | sudo apt-get update && sudo apt-get install jq - + release_version=${GITHUB_REF#*release-} if [ "$(cat version.json | jq -r '.version')" != "$release_version" ] then @@ -29,4 +29,4 @@ jobs: - uses: actions/checkout@v3 - name: Deploy run: | - echo deploying into Test env \ No newline at end of file + echo deploying into Test env diff --git a/.idea/.gitignore b/.idea/.gitignore new file mode 100644 index 0000000..26d3352 --- /dev/null +++ b/.idea/.gitignore @@ -0,0 +1,3 @@ +# Default ignored files +/shelf/ +/workspace.xml diff --git a/.idea/inspectionProfiles/profiles_settings.xml b/.idea/inspectionProfiles/profiles_settings.xml new file mode 100644 index 0000000..105ce2d --- /dev/null +++ b/.idea/inspectionProfiles/profiles_settings.xml @@ -0,0 +1,6 @@ + + + + \ No newline at end of file diff --git a/.idea/misc.xml b/.idea/misc.xml new file mode 100644 index 0000000..d1e22ec --- /dev/null +++ b/.idea/misc.xml @@ -0,0 +1,4 @@ + + + + \ No newline at end of file diff --git a/.idea/vcs.xml b/.idea/vcs.xml new file mode 100644 index 0000000..35eb1dd --- /dev/null +++ b/.idea/vcs.xml @@ -0,0 +1,6 @@ + + + + + + \ No newline at end of file diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 0000000..eab9bab --- /dev/null +++ b/.pre-commit-config.yaml @@ -0,0 +1,9 @@ +# See https://pre-commit.com for more information +# See https://pre-commit.com/hooks.html for more hooks +repos: + - repo: https://github.com/Yelp/detect-secrets + rev: v1.4.0 # Check for the latest release + hooks: + - id: detect-secrets + +# diff --git a/README.md b/README.md index b12e2ab..337c049 100644 --- a/README.md +++ b/README.md @@ -4,17 +4,17 @@ 1. Fork this repo and clone your forked repo locally. **Make sure you fork ALL branches, not only `main`** 2. Answer the below questions, commit your results and push them to the forked repo (make sure you push all the involved branches). -3. Create a PR from branch `main` of your forked repo into `main` of the original repo. +3. Create a PR from branch `main` of your forked repo into `main` of the original repo. 4. Make sure you pass automatic tests. -## Branches +## Branches -Create the following git commit tree. You can add any file you want in each commit. -The message for each commit is denoted in the graph (`c1`, `c2`,..., `c12`). -Note the (lightweight) tags in commit `c4` and `c8`. +Create the following git commit tree. You can add any file you want in each commit. +The message for each commit is denoted in the graph (`c1`, `c2`,..., `c12`). +Note the (lightweight) tags in commit `c4` and `c8`. Make sure to create exactly these names for branches and commit messages. -The parent commit of `c1` should be the last commit in branch `main` after a fresh clone of this repo (commit with message `start here`). +The parent commit of `c1` should be the last commit in branch `main` after a fresh clone of this repo (commit with message `start here`). ```mermaid gitGraph @@ -62,13 +62,13 @@ bash branches.sh **It's highly recommended to use a conflict merge tool (like the built-in one in PyCharm and VSCode).** -Your team colleagues, John Doe and Narayan Nadella, are working together on the same task. -Each one of them is working on his own git branch. +Your team colleagues, John Doe and Narayan Nadella, are working together on the same task. +Each one of them is working on his own git branch. - John Doe developed under `origin/feature/version1` branch. - Narayan Nadella developed under `origin/feature/version2` branch. -Both checked out from the same `main` branch. +Both checked out from the same `main` branch. You decide to create a new branch called `feature/myfeature` and merge the work of John and Narayan into your branch. You'll encounter a conflict. @@ -87,7 +87,7 @@ cd test bash conflict.sh ``` -## Pre-commit and sensitive data +## Pre-commit and sensitive data In this repo, there is a commit which contains credentials of strong identity in AWS. The file contains the credentials might look like: @@ -97,7 +97,7 @@ AWS_ACCESS_KEY_ID=AKIA6BJMA3TKBADSHFXZ AWS_SECRET_ACCESS_KEY=op7N48fxIFxh06ToUwZd33emso/QKZWb/2M5fgTX ``` -Your goal is to find this commit, and completely remove it from the history. +Your goal is to find this commit, and completely remove it from the history. Here is an illustration of the vulnerable commit (the true branch name is not `some_branch`): @@ -111,7 +111,7 @@ gitGraph commit id: "commit 3" ``` -And after your fix: +And after your fix: ```mermaid gitGraph @@ -125,17 +125,17 @@ gitGraph Note that commits behind the vulnerable commit should remain untouched (like `commit1`), while commit ahead the vulnerable commit might change (like `some other commit 2` and `some other commit 3`, instead of `commit 2` and `commit 3`). -Commit-wise, you are free to do whatever you wish for commits that are coming after the vulnerable commit, as far as **the content of the branch remain the same**. -The branch content should be identical to what it was before your fix, except the vulnerable file that was committed in the `VULNERABLE_COMMIT` commit. +Commit-wise, you are free to do whatever you wish for commits that are coming after the vulnerable commit, as far as **the content of the branch remain the same**. +The branch content should be identical to what it was before your fix, except the vulnerable file that was committed in the `VULNERABLE_COMMIT` commit. There are many approaches to solve it, some are using `git reset --hard`, `git rebase` or `git cherry-pick`. Find your preferred way. -You should find the branch contains the vulnerable data, learn its structure and data, and remove the vulnerable commit carefully, without loosing data committed in other commits. +You should find the branch contains the vulnerable data, learn its structure and data, and remove the vulnerable commit carefully, without loosing data committed in other commits. -Since you've changed the commit history, you may be needing to `--force`fully push your fixed branch to remote. +Since you've changed the commit history, you may be needing to `--force`fully push your fixed branch to remote. In order to prevent this vulnerability in the future, integrate [pre commit](https://pre-commit.com/) into your repo, and add a plugin that blocks any commits that contains AWS credentials data. Verify that the tool is working - try to commit the below text and make sure pre-commit is blocking you. -If you were able to commit it, `git reset` your working branch to the commit before the vulnerable commit, and try again. +If you were able to commit it, `git reset` your working branch to the commit before the vulnerable commit, and try again. ### Test it locally @@ -156,9 +156,9 @@ In the Gitflow model, the main branches are: - Feature branches (starts with `feature/...`): These branches are used for developing new features and should be branched off from the `dev` branch. Once the feature is complete, it is merged back into `dev` via a **Pull Request**. If everything is ok and ready to be deployed in production, the branch owner opens a Pull Request from the branch into `main`. - Release branches (starts with `release-*`) for preparing releases. Once the code in a release branch is stable. It is merged into both `dev` and `main`. Any necessary bug fixes for the release are done in this branch. -Your goal is to implement gitflow workflow in this repo. +Your goal is to implement gitflow workflow in this repo. -**Tip**: You can always start over again by deleting the `dev`, release and feature branches (also from remote if needed), and use the `git reset --hard ` command to reset the `main` branch to certain commit, while `` is the commit id last before you start this question. +**Tip**: You can always start over again by deleting the `dev`, release and feature branches (also from remote if needed), and use the `git reset --hard ` command to reset the `main` branch to certain commit, while `` is the commit id last before you start this question. 1. First, create the following [protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) in your GitHub repo: 1. `dev` branch is not allowed to being pushed directly, only via Pull Request. @@ -168,24 +168,24 @@ Your goal is to implement gitflow workflow in this repo. 3. From `dev` create some feature branch. 4. Create a **Pull Request** from your feature branch into `dev`, review the PR, and finally merge it into `dev` (don't use fast-forward!). 5. Observe the created GitHub action job that responsible to "deploy" the updated branch `dev` into **Development** environment (you may need to enable GitHub actions in your account - it's free). -6. From the merge commit created by the PR, create a release branch. You can call it `release-v1.2` for example. +6. From the merge commit created by the PR, create a release branch. You can call it `release-v1.2` for example. 7. Commit some more changes in the release branch. Those changes are simulate some tiny fixes you've received from QA, some typos the product manager has fixed, and release specific content. 8. Push your release branch. Observe who is the GitHub action jos "deploying" this release to **Test** environment (also known as **Stage** env). Make your fixes if needed. -9. Once you're satisfied with results, ask your release manager (which is you) to merge your new release into `main`, push `main` and observe how the created GitHub action job is "deploying" the release to ☠️**Production** env☠️. +9. Once you're satisfied with results, ask your release manager (which is you) to merge your new release into `main`, push `main` and observe how the created GitHub action job is "deploying" the release to ☠️**Production** env☠️. In GitHub actions, workflows are defined using YAML syntax in `.github/workflows` directory of your repository. Take a look into `.github/workflows/prod.yaml` file, which defines Production deployment pipeline. -Edit the workflow yaml file, such that the workflow is aborted when the user triggered it is not the release manager. +Edit the workflow yaml file, such that the workflow is aborted when the user triggered it is not the release manager. -## Merge two git repositories +## Merge two git repositories In a company implementing typical DevOps pipelines, different teams may be responsible for developing separate microservices of a larger application, each residing in its own Git repository. -You have been assigned the task of merging two different Git repositories, each containing separate microservices, into a single [monorepo](https://www.atlassian.com/git/tutorials/monorepos). -The repositories were maintained by separate teams and have separate commit histories. +You have been assigned the task of merging two different Git repositories, each containing separate microservices, into a single [monorepo](https://www.atlassian.com/git/tutorials/monorepos). +The repositories were maintained by separate teams and have separate commit histories. Your goal is to **preserve the entire commit history** of both repositories while merging the code into a single Git repository, ensuring that the microservices remain functional and properly integrated with each other. -Merge the [GitExerciseOther](https://github.com/alonitac/GitExerciseOther.git) repo into this (GitExercise) repository. +Merge the [GitExerciseOther](https://github.com/alonitac/GitExerciseOther.git) repo into this (GitExercise) repository. The `main` branch of the monorepo should have the following file structure: ```text @@ -198,9 +198,9 @@ GitExercise ### Notes -- You are to choose what to do in the files of the GitExerciseOther repo that don't under `serviceB` directory. -- You can commit any further change (e.g. move files into some directory) after the history of the GitExerciseOther repo has been successfully merged into this repo. -- In case of conflicts during the merge, you should prefer this repo's version. +- You are to choose what to do in the files of the GitExerciseOther repo that don't under `serviceB` directory. +- You can commit any further change (e.g. move files into some directory) after the history of the GitExerciseOther repo has been successfully merged into this repo. +- In case of conflicts during the merge, you should prefer this repo's version. ### Test it locally @@ -211,5 +211,3 @@ bash merge_repos.sh ``` # Gook Luck - - diff --git a/app.py b/app.py index 8012390..873810d 100644 --- a/app.py +++ b/app.py @@ -40,5 +40,3 @@ def home(): if __name__ == "__main__": app.run(debug=True, port=22, host="0.0.0.0") - - diff --git a/serviceA/package.json b/serviceA/package.json index 9e26dfe..0967ef4 100644 --- a/serviceA/package.json +++ b/serviceA/package.json @@ -1 +1 @@ -{} \ No newline at end of file +{} diff --git a/some_file2 b/some_file2 new file mode 100644 index 0000000..cd2e9ba --- /dev/null +++ b/some_file2 @@ -0,0 +1 @@ +cf3ca4fb8d148a2d3985fb98c7298323 diff --git a/some_other_file2 b/some_other_file2 new file mode 100644 index 0000000..4ecbe09 --- /dev/null +++ b/some_other_file2 @@ -0,0 +1 @@ +8e6d96258cd50ff6af10ef9a6574c206 diff --git a/test/branches.sh b/test/branches.sh index 7cfdbb3..9af2d6d 100644 --- a/test/branches.sh +++ b/test/branches.sh @@ -98,4 +98,4 @@ git checkout main echo -e "\n\nWell done! branching question was completed successfully!\n\n" -# TBD check c7 c8 nit in main \ No newline at end of file +# TBD check c7 c8 nit in main diff --git a/test/conflict.sh b/test/conflict.sh index 08ff69f..9776619 100644 --- a/test/conflict.sh +++ b/test/conflict.sh @@ -38,5 +38,3 @@ then echo "Bad service price" exit 1 fi - - diff --git a/test/merge_repos.sh b/test/merge_repos.sh index f92e4e7..3f805a8 100644 --- a/test/merge_repos.sh +++ b/test/merge_repos.sh @@ -18,4 +18,4 @@ for file in "${files[@]}"; do fi done -echo -e "\n\nGood repositories merge!" \ No newline at end of file +echo -e "\n\nGood repositories merge!" diff --git a/version.json b/version.json index 089f401..16233d2 100644 --- a/version.json +++ b/version.json @@ -1,3 +1,3 @@ { "version": "v1.2.3" -} \ No newline at end of file +}