Note, this challenge has a shorter timeline, we only have 96 hours for submission, 24 hours for review phase, 24 hours for appeal and 12 hours for appeal response.  
 
���     Target environment: Rally, Bitbucket, NodeJS CLI tool
���     Basic Requirements: Connect VSCode to Rally workspace, retrieve data from Rally and display on VSCode editor.
 
Now Rally is renamed to CA Agile Central, but we still use Rally as the name in this specification.

Project Background

We have already completed a project of nodejs scripts for Bitbucket-Rally integration. These scripts include a library for Bitbucket integration using both the V1 and V2 API. There is also a collection of libs for interacting with Rally and a CLI to simplify processing actions.
 
Our client wants to these scripts transposed (re-written) into exemplary Typescript using proper classes, interfaces, and types and makes sure both V1 and V2 REST APIs for Bitbucket are supported for all necessary functions.
 
In addition, the client would like to add more features to make it more user-friendly,

Technology Stack

-      Rally API
-      BitBucket API V1 & V2
-      Git
-      NodeJS
-      Typescript
-      Lerna
-      Jenkins

Individual requirements

In the previous challenge, we transported the original NodeJS CLI code into Typescript. In this challenge, we need to add more features to enhance the UX of the CLI tool.
 
You can install the CLI tool globally, by switching to the root directory of ci-grit and run
 
npm install -g
 
Then you can run the CLI tool command ci-grit on the git repo directory.
 

1. Remove related configuration

1.1 BitBucket configuration

See packages/bitbucket/config/default.ts
 
// Bibucket Config
export const BITBUCKET_SETTINGS = {
  apiUrl: env.BITBUCKET_API_URL
    || 'https://api.bitbucket.org/2.0/repositories/lauren-edwards/rally-changeset-test',
  username: env.BITBUCKET_API_USERNAME || 'lauren-edwards',
  password: env.BITBUCKET_API_PASSWORD || 'taiQueiV1ee',
  repoName: env.BITBUCKET_REPO_NAME || 'rally-changeset-test'
};


You should remove username, password, repoName from the configuration, and the apiUrl and BITBUCKET_API_URL should be unrelated to the username and repoName. For example, the Bitbucket V2 API URL, it should be https://api.bitbucket.org/2.0/
 

1.2 Rally configuration

See packages/rally/config/default.ts
 
// Rally Config
export const RALLY_SETTINGS = {
  apiKey: env.RALLY_API_KEY,
  server: env.RALLY_SERVER || 'https://rally1.rallydev.com',
  workspace: env.RALLY_WORKSPACE || '',
  filterInProgress: String(env.RALLY_FILTER_IN_PROGRESS || false).toLowerCase() === 'true',
  authorIdField: env.RALLY_AUTHOR_ID || 'Description',
  commitPrefixes: env.RALLY_COMMIT_PREFIXES || 'US, DE, TA',
  assignedToStory: String(env.RALLY_ASSIGNED_TO_STORY || false).toLowerCase() === 'true',
  buildDefinitionName: env.RALLY_BUILD_DEFINITION || 'customBuildDefinition',
  repository: env.RALLY_REPO || null
};


You should remove apiKey and workspace from the configuration, these should be queried from user input and persisted by repo.
 

2. Git repo input and detection

 
If you run ci-grit under a non-git repo directory, then you should specify a command line parameter --git-remote-url to specify the remote git URL.
 
For example, if we run ci-grit --git-remote-url https://billsedison@bitbucket.org/billsedison/chalk-fork.git, the workflow is
-Clone the remote repo to the local git directory.
-Switch the current directory to the local git directory.
-Automatically run 3. Query and store user credentials to query and store the user's credentials.
 
If you run ci-grit under a git repo directory, then detect the current git repo remote upstream URL, if there are multiple upstream URLs configured in the git repo, only check origin.
 
Error handling
-If you run under a non-git repo directory but don't specify the parameter, just print the usage and exit.
-If you run under a non-bitbucket git repo directory, print an error message to denote “Sorry, ci-grit only supports bitbucket git repo”.
 

3. Query and store user credentials

 
At the first time of running the ci-grit tool on a git repo directory, it should provide an interactive command line to query user's credentials.
 
The user credentials include
-Git username/password of the git repo remote upstream (should be Bitbucket username/password) for now.
-Rally API Key
-Rally workspace
 
Once the user input all the credentials, ci-grit should store the credentials into the local git repo directory.
-For Git username/password and Rally API Key, it should be stored in .git/config, it is an INI file inside the .git directory, you can add extra items.
-For Rally workspace, create a new file .gritrc, and store the Rally workspace, the format of .gritrc should be JSON formatted. .gritrc can be pushed to the remote git repo.
 
So the next time of running the ci-grit tool on the git repo directory, it should get credentials from these files, and don't ask the user to input again.
 

4. Create a pull request via the CLI tool

 
Currently, ci-grit only has a command ci-grit --pull-request merge to merge the existing pull request. In this challenge, we need to add a new command to create a new pull request.
 
The usage of the command should be
 
ci-grit --pull-request create [--target-repo <target-repo>] [--target-branch <target-branch>]
 
Here are the parameter descriptions
-target-repo: Optional. The target git repo remote URL. You can assume the current user has access to the target git repo. If it's not specified, then it should be the upstream URL of the current local git folder.
-target-branch: Optional. The target branch name to merge to. If it's not specified, then it should be the master branch. Assume the repo must have a master branch.
 
After running the command, ci-grit will create a pull request from the source-repo/source-branch to target-repo/target-branch.
 
Where:
-source-repo is the remote upstream repo of the current local git directory.
-source-branch is the current branch.
 
ci-grit will validate if the local git repo is synchronized with the remote upstream git repo well. Only a synchronized repo is good to create a pull request.
 
You should validate the following items sequentially.
Here is the pseudo-code to describe the workflow above.
 

// 1) Any local changes that have not been staged?
if (Any local changes that have not been staged) {
	list all these files;
	prompt a question to ask if the user wants to continue or decline;
	if (user wants to decline) {
		exit;
	}
}
 
// 2) Any untracked files that have not been staged?
if (Any untracked files that have not been staged) {
	list all these files;
	prompt a question to ask if the user wants to continue or decline;
	if (user wants to decline) {
		exit;
	}
}
 
// 3) Any staged files that have not been committed? 
if (Any staged files that have not been committed) {
	list all these files;
	prompt a question to ask if the user wants to continue or decline;
	if (user wants to decline) {
		exit;
	}
}
 
// 4) Any committed files that have not been pushed?
if (Any committed files that have not been pushed) {
	list all these files;
	prompt a question to ask if the user wants to continue or decline;
	if (user wants to decline) {
		exit;
	}
}
 
// 5) Any commits in the upstream branch that has not been pulled?
if (Any commits in the upstream branch that has not been pulled) {
	list all these commits;
	prompt a question to ask if the user wants to continue or decline;
	if (user wants to decline) {
		exit;
	}
}
 
// 6) If the current repo is a fork of the target repo, check any commits in the target-repo/target-branch that have not been pulled?
if ((the current repo is a fork of the target repo) && (any commits in the target-repo/target-branch that have not been pulled)) {
	list all these commits;
	prompt a question to ask if the user wants to continue or decline;
	if (user wants to decline) {
		exit;
	}
}
 
// 7) Check if there is already a pull request from source-repo/source-branch to target-repo/target-branch?
if (there is already a pull request from source-repo/source-branch to target-repo/target-branch) {
	prompt a question to ask if the user wants to override the existing pull request or not;
	if (user doesn't want to override) {
		exit;
	}
}
 
// 8) Add a description of the pull request, not mandatory (can be empty), jump to 9)
add a description of the pull request (optional);
 
// 9) Assign any reviewers (or none) to the pull-request. The reviewers are from the contributors of the current local git repo
prompt a question to ask if the user wants to assign any reviewers;
if (user wants to assign reviewers) {
	if (there is a package.json in the current git repo) {
		if (there is a contributors field in the JSON) {
			The user selects one contributor as the reviewer;
			call BitBucket API to get the reviewer details;
		} else {
			prompt there are no contributors
		}
	} else {
		prompt there are no contributors;
	}
}
 
// 10) Create the pull request to Bitbucket, after the pull request is created successfully, show the remote link of the pull request in the console
await Create the pull request to Bitbucket;
show the remote link of the pull request in the console;

 
Hints

• The client provides a sample node script that has implemented the pull request creation logic. The code is attached to the forum. I will also provide some import functions from the code of the tool for your reference, it will be helpful for you to address some functionalities implementation.
• Note you don't have to follow the same implementation or any code style of the script, the code is just for reference and you can get some hints about how to implement some functionalities from it.
• All these functionalities should be implemented in @grit-cli/bitbucket module (the code is in packages/bitbucket)
• In the forum, I provided some useful functions from the tool code for your reference, please kindly check. 

5 Unit test update

 
For the code of the new functionality, you should write unit tests in mocha and chai.
 

6 Documentation update

 
Please update README.md accordingly.
 
Please add a verification document CREATE-PULL-REQUEST-VALIDATION.md in docs/ directory.
 
Please provide a video, preferably you uploaded the video to Youtube/GoogleDrive/Dropbox etc and include the link in the document. Youtube video should be unlisted.
 

Codebase

-https://gitlab.com/ci-grit/ci-grit.git
-master branch
-Target commit hash: 181665df9a9dbc7fe427d6c599beafa8c6c811a8
 
If you don't have access to the repo, you can grant yourself access via a Topcoder-X link. The link is shared in the forum.

To reviewers

You will need to set up your own Rally workspace to review. Competitors won't share their Rally credentials or API keys with you.
 
Note, this challenge has a shorter timeline, we only have 96 hours for submission, 24 hours for review phase, 24 hours for appeal and 12 hours for appeal response.

Final Submission Guidelines

Please submit the following items in a zip archive.
 
-The git patch against commit hash 181665df9a9dbc7fe427d6c599beafa8c6c811a8
-A separate README that contains how to apply your git patch.
-For other requirement documentation update, please include it in your patch.
-A video to verify your CLI tool meets all requirements. If you are not comfortable with spoken English you may feel free to annotate your video with text.