Giter Site home page Giter Site logo

rally's Introduction

Rally + GitHub

A GitHub App in active development built with Probot that integrates Rally (a project management tool) with GitHub. It can be configured to:

  • Check the title of a Pull Request for valid Rally artifacts
  • Check the body of a Pull Request for valid Rally artifacts
  • Check the commit messages of a Pull Request for valid Rally artifacts

The GitHub App will update the Checks API with success/failure as the conditions are met, and provide a detailed report of the artifacts (i.e. defects, user stories) found and their Flow States in Rally.

Get Started

checks-status

rally-pr-connection

How it Works

Every time a pull request is created or updated, Rally + GitHub will check for the existence of a Rally User Story or Defect in the title, body, or commit messages, and then validate that they are in the correct state in Rally.

---
# Name of the GitHub Check
checksName: integrations/rally

# Check PR Body for Rally story/defect (true | false)
checkPRBody: true

# Check PR Title for Rally story/defect (true | false)
checkPRTitle: true

# Check all commit messages for a Rally story/defect (true | false)
checkCommitMessages: true

# Set Rally Flow State to Complete on merge if the PR Body contains "/completes <DEFECT/STORY ID>"
mergeOnPRBody: true

# Comment on the PR in addition to the check message? (true | false)
commentOnPull: false

rally:
  server: https://rally1.rallydev.com

  ## Leave these blank if you use an API key
  ##username: rallyUser
  ##password: rallyPass
  ## This is required if we don't use username/password
  ## NOTE: If you set this in your .env file then you can
  ## leave this commented out. It will override your .env
  #api_key: _1234abc567...

  # Which workspace OID this repo will link to
  workspace: 12345

  # Which projects this repo will link to.
  # To have it connect to any project, leave this value blank
  # Optional - Leave it commented or set to `Any` to allow from any
  #            project in the workspace
  projects:
    - Sample Project
    - devops-engineering

  # List of valid Rally objects to check
  objects:
    - defect
    #- defectsuite
    #- task
    #- testcase
    #- hierarchicalrequirement
    - userstory
    #- story

  # List of Rally states that an issue must be in in order to pass
  states:
    - Defined
    - In-Progress

Creating the GitHub App on your GitHub instance

  • You can follow the detailed documentation at Creating a GitHub App. Below is the condensed version of the documentation

  • On your GitHub instance, visit the settings page on the Organization that you want to own the GitHub App, and navigate to the GitHub Apps section.

    • You can access this page by visiting the following url: https://<MY_GITHUB_HOSTNAME>/organizations/<MY_ORG_NAME>/settings/apps
  • Create a new GitHub App with the following settings:

    • Webhook URL: URL of the machine on which this app has been deployed (Example: http://ip.of.machine:3000)
    • Homepage URL: URL of the machine on which this app has been deployed (Example: http://ip.of.machine:3000)
    • Webhook Secret: REQUIRED The webhook secret that will be or has been defined as an environment variable in your deployment environment as WEBHOOK_SECRET
    • Permissions:
      • Checks: Read & write
      • Commit statuses: Read & write
      • Contents: Read-only
      • Metadata: Read-only
      • Pull Requests: Read & write
      • Issues: Read & Write
    • Events:
      • Pull request
      • Check run
      • Check suite
      • Push
  • Once these have been configured, select the Create GitHub App button at the bottom of the page to continue

  • Make a note of the APP ID on your newly-created GitHub App. You will need to set this as an environment variable when you configure the app.

  • Generate and download a private key from the new App page, and store it in your deployment environment. You can either do this by saving the contents of the key file as the environment variable PRIVATE_KEY, or by saving the file directly in the environment and specifying its path with the environment variable PRIVATE_KEY_PATH

  • After you have created the GitHub App, you will need to install it to the desired GitHub Organizations.

    • Select Install App
    • Select All Repositories or the desired repositories you wish to watch

Deployment

Rally + GitHub is based on the Probot framework and can be deployed as a standard NodeJS application. Ensure that NPM is installed in your deployment environment. Also ensure that the following environment variables are configured. Note: You can also deploy as a Docker container. Please view the Docker Deployment Doc for more info.

# Clone repository to local machine
git clone https://github.com/github/rally

# Change directories into code base
cd rally

# Install all dependencies
npm install

# Create the .env configuration file and update with all needed variables
cp .env.example .env
vi .env
# update .env with configuration variables

# Run the bot
npm start

# Run the bot in the background and output to log
# there are other major ways to achieve this...
# https://github.com/unitech/pm2
# https://github.com/github/auto-fork-sync#running-with-systemd
# https://www.npmjs.com/package/forever
nohup npm start 2>&1 >> /path/to/output.log &

Environment Variables

  • APP_ID - The App ID of the GitHub App
  • BOT_NAME - The name of the bot
  • WEBHOOK_SECRET - The secret to prevent man in the middle attacks
  • GHE_HOST - This is a required field for GitHub Enterprise Server implementations (Example: github.mycompany.com)
  • RALLY_SERVER - URL to connect to Rally
  • RALLY_USERNAME - Username to authenticate to Rally
  • RALLY_PASSWORD - Password to RALLY_USERNAME to authenticate to Rally (Note: RALLY_API_KEY is preferred method)
  • RALLY_API_KEY - API key to authenticate to Rally instead of RALLY_USERNAME and RALLY_PASSWORD rally-token
  • ENFORCE_ALL_REPOS - true or false, will set enforcement of Rally + GitHub on all repositories in the installed Organization
  • ORG_CONFIG_REPO_NAME - Repository name where an organization-level configuration can set default behavior for all repositories (Default: .github)

One of the following is required:

  • PRIVATE_KEY - The contents of the private key for your GitHub App. If you're unable to use multi-line environment variables, use base64 encoding to convert the key to a single line string.
  • PRIVATE_KEY_PATH - The path to the .pem file for your GitHub App. (Example: PRIVATE_KEY_PATH='path/to/key.pem')

How users can consume Rally + GitHub App

Once you have the GitHub App up and running, users will need to add the configuration file to master branch to have the GitHub App validate their repositories: .github/rally.yml

  • Having this file in the root of the repository is what signals the Rally + GitHub App to view all configured events for the repository
  • The configuration file allows users to make small customizations to how the bot interacts with their codebase
  • Users will also want to configure protected branches to help make sure all rules are followed and enforced by the validator bot
  • If a default configuration for all repositories in an organization is desirable, create a .github/rally.yml file in a repository called [ORG_NAME]/.github.
    • The name of this configuration repository can also be set as an environment variable (i.e., this bot can look in a repository other than [ORG_NAME]/.github).
    • Additionally, if a per-repository configuration needs to be managed from this central configuration repository, create such configuration files under a folder named .github/rally (e.g., .github/rally/[REPO_NAME].yml).
    • Please note that the rally.yml file must still be placed in a .github folder, even if the repository itself is named .github (at least at the time of this update).

How to contribute

We invite you to contribute to this GitHub App! Check out Issues (especially those labeled help wanted or good first issue) and jump over to CONTRIBUTING for more details.

License

This project uses the MIT license

rally's People

Contributors

admiralawkbar avatar colossus9 avatar davidstaheli avatar dependabot[bot] avatar dwhathaway avatar hubot avatar iamhughes avatar ineffyble avatar joshuathemiller avatar nnordrum avatar omendrapandey avatar parkerbxyz avatar rneatherway avatar rrotaru avatar steffen avatar stoe avatar vorobievalex avatar zkoppert avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rally's Issues

Rally authentication no longer works

Describe the bug
Authentication to the Rally API no longer works.

18:33:18.950Z DEBUG github: GitHub request: POST /repos/:owner/:repo/check-runs - 201 Created (installation=61)
...
    "owner": "GitHub-Demo",
    "repo": "probot-rally",
    "name": "rally/validator",
    "head_branch": "debug1",
    "head_sha": "6e4b21c4ec2902d1df7b8fab35cd58050cef5202",
    "status": "completed",
    "started_at": "2020-08-11T18:33:18.014Z",
    "conclusion": "failure",
    "completed_at": "2020-08-11T18:33:18.014Z",
    "output": {
      "title": "Rally artifact validation failed",
      "summary": "Error occurred while validating Rally Artifacts: Error: /hierarchicalrequirement: 401! body=<html>\n<head>\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"/>\n<title>Error 401 Full authentication is required to access this resource</title>\n</head>\n<body><h2
>HTTP ERROR 401</h2>\n<p>Problem accessing /slm/webservice/v2.0/hierarchicalrequirement. Reason:\n<pre>    Full authentication is required to access this resource</pre></p><hr><i><small>Powered by Jetty://</small></i><hr/>\n\n</body>\n</html>\n"
    }
  }
18:33:18.955Z ERROR probot:
  /hierarchicalrequirement: 401! body=<html>
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
  <title>Error 401 Full authentication is required to access this resource</title>
  </head>
  <body><h2>HTTP ERROR 401</h2>
  <p>Problem accessing /slm/webservice/v2.0/hierarchicalrequirement. Reason:
  <pre>    Full authentication is required to access this resource</pre></p><hr><i><small>Powered by Jetty://</small></i><hr/>

  </body>
  </html>

  --
  Error: /hierarchicalrequirement: 401! body=<html>
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
  <title>Error 401 Full authentication is required to access this resource</title>
  </head>
  <body><h2>HTTP ERROR 401</h2>
  <p>Problem accessing /slm/webservice/v2.0/hierarchicalrequirement. Reason:
  <pre>    Full authentication is required to access this resource</pre></p><hr><i><small>Powered by Jetty://</small></i><hr/>

  </body>
  </html>

      at generateError (/opt/rally/node_modules/rally/dist/request.js:38:11)
      at Request._callback (/opt/rally/node_modules/rally/dist/request.js:114:20)
      at Request.self.callback (/opt/rally/node_modules/request/request.js:185:22)
      at Request.emit (events.js:311:20)
      at Request.EventEmitter.emit (domain.js:482:12)
      at Request.<anonymous> (/opt/rally/node_modules/request/request.js:1154:10)
      at Request.emit (events.js:311:20)
      at Request.EventEmitter.emit (domain.js:482:12)
      at Gunzip.<anonymous> (/opt/rally/node_modules/request/request.js:1076:12)
      at Object.onceWrapper (events.js:417:28)
      at Gunzip.emit (events.js:323:22)
      at Gunzip.EventEmitter.emit (domain.js:482:12)
      at endReadableNT (_stream_readable.js:1204:12)
      at processTicksAndRejections (internal/process/task_queues.js:84:21)

To Reproduce
Steps to reproduce the behavior:

  1. Create the GitHub App
  2. Configure the bot
  3. Add the config to .github/rally.yml
  4. Open a pull request

Expected behavior
Expected behavior is that we see the checks as shown in the README

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
This was discovered using the exact same test repo that was used for initial development, but the latest code was pulled down

Can we package releases to a Docker registry?

Describe the solution you'd like
Can we package and publish a Docker image for releases of this repository? It may be easier for users to run a pre-built image and pass in environment variables in their setup rather than the .env file.

Feature: Enable support for validating, but not failing checks

In some cases, users may want to validate linked user stories if one is found, but not require the user story in the PR. This would require a few options:

  1. Check the title, body and commit messages for user stories
  2. Lookup and link any found user stories
  3. Do not fail when user stories are missing
  4. Fail when identified user stories are invalid

Duplicate Projects and valid artifact states

Your issue may already be reported!
Please search on the issue tracker before creating one.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Configure the integration
  2. Add .github/rally.yml to the rally-github-config global repository
  3. Add .github/rally.yml to the repo you'll test with
  4. Projects are copied from both the global and local config, duplicating the output

Expected behavior
The config is read from either the global config or the local config

Screenshots
2020-08-11_17-11-45

Additional context
Add any other context about the problem here.

Licensing for open source

In an effort to open source this repository, we need to select a license under which to release it. The standard and suggestion is to use an MIT license. Any issues or concerns with going with that? Any suggestions for using a different license for any reason?

Options for usage with Github.com and hosting the app

Howdy, folks!

Congrats on releasing another helpful integration. I'm very interested as someone utilizing both tools in scope with home-grown solutions this could replace. Thank you for sharing this with the community!

For context, I currently run on repositories a custom GitHub Action that checks URL/Format of Rally references in Pull Request Description fields to encourage population of the Rally Connection tabs.

re: github.com support

The release and docs make this seem to be largely targeting GitHub Enterprise Self-hosted. However, being backed by a probot app, it does look like the setup could be altered a bit to make that work with Github.com. If Github.com (or GitHub Enterprise Cloud) isn't supported yet, are there plans to?

re: Hosting options

For alternative hosting options, is there a viable/known path of hosting GitHub Probot or GitHub Apps via GitHub Actions? Could there be a path of utilizing repository_dispatch events?

Cheers,
@cj-taylor

Remove hard-coded reference to 'master' branch

We're presently looking for the .github/rally.yml file and specifying the master branch. I don't think it's necessary to specify the branch unless we're looking for something other than the default. As we look to keep things compatible with future changes in light of our effort to move to main, it's probably better to leave out these two lines and allow the app to use the default branch.

https://github.com/github/rally/blob/main/lib/RallyValidate.js#L95

https://github.com/github/rally/blob/main/lib/RallyValidate.js#L109

TypeError: rallyArtifacts.labelList is not iterable

When testing the bot, the following error displays in the PR checks:


Rally artifact validation failed

Error occurred while validating Rally Artifacts: TypeError: rallyArtifacts.labelList is not iterable

Is Python required for Probot?

Hi all,

In the Dockerfile (line 30-31):

## We need Python for Probot
RUN apk add --no-cache make python

I am not sure which dependency requires Python, I have been running the app without Python for a few weeks, I haven't noticed any errors.

Regards,
Emre

Branch name validation

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Having a configuration option to validate the branch name in PR.
For example;
# Check PR branch name for Rally story/defect (true | false)
checkPRBranchName: true

If the branch name contains a Rally story/defect validation is successful.

Describe alternatives you've considered
We are currently also checking PR title and PR body, however majority of NAB devs use Stories/Defects as branch names.

Additional context
I can create a PR for this, if required.

Remove label validation from README

Due to the fact that validating labels would potentially create thousands of one-time-use labels on each repo the feature was removed in #38... we should also remove the references from the README

feature: add setup page for app

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
In addition to the manual setup, having a UI to enter the required settings in .env would help users get off the ground

Describe alternatives you've considered
Existing manual setup

Additional context
Concept:
2020-08-27_13-52-53

Note
If this is a request to add a new language, after submitting this issue check out the wiki for more info on how to accomplish that.

Error: Not able to parse artifact type: undefined

Describe the bug
Using a lowercase Rally Story Id in the pull request body is resulting in an exception.
"Error occurred while validating Rally Artifacts: Error: Not able to parse artifact type: undefined"

To Reproduce
Steps to reproduce the behavior:

  1. Create a new PR
  2. in the body of the PR add a Rally story usxxxx (lower case us)
  3. check the Rally integration details
  4. see the error "Error occurred while validating Rally Artifacts: Error: Not able to parse artifact type: undefined"

Expected behavior
If this is considered an invalid Rally Story id, we should get a validation failed result rather than an exception.
The other option is making the check case insensitive.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
If you edit the PR body, and change the story id to upper case, this fixes the issue.

Here's my test config file:

---
# Name of the GitHub Check
checksName: integrations/rally

# Check PR Body for Rally story/defect (true | false)
checkPRBody: true

# Check PR Title for Rally story/defect (true | false)
checkPRTitle: false

# Check all commit messages for a Rally story/defect (true | false)
checkCommitMessages: false

# Set Rally Flow State to Complete on merge if the PR Body contains "/completes <DEFECT/STORY ID>"
mergeOnPRBody: true

# Comment on the PR in addition to the check message? (true | false)
commentOnPull: false

rally:
  server: https://rally1.rallydev.com
  workspace: xxxxxxxxxxx

  # Which projects this repo will link to.
  projects:
    - TEST Squad 1
    - TEST Squad 2

  # List of valid Rally objects to check
  objects:
    - defect
    - task
    - userstory
    - story

  # List of Rally states that an issue must be in in order to pass
  states:
    - Ready
    - Defined
    - In-Progress

Support Global Configuration

The bot worked great, just a small feedback can go a long way for my company. Let me know if this is possible.

  1. Provide a way to not require Rally Project name and instead search work items in the whole workspace (American).
  2. Provide a way to not require yml configuration per repo and instead control it at the github ORG level so that all repos get scanned with same configuration.

Feature: Run checks on push event.

Describe the solution you'd like
I'd like to be able to run the check suite on all commits or on commits within specific branches (without an associated pull request).

Additional context
Currently, the check suite only runs on pull-request payload events. The previous webhook integration for Rally supported a per-commit validation of user story IDs (this would only work if the rally.yml was configured to check the commit message title or body).

Update CodeQL analysis to use new repository

I don't have write access to open a PR but here's how the codeql.yml file should look.

name: "CodeQL analysis"

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: github/codeql-action/init@v1
      with:
        languages: javascript
    - uses: github/codeql-action/analyze@v1

The bulk of this change is updating to use the new repository name and branch, so this repository will get up to date feature and bug fixes for the codeql-action and code scanning. I've also removed some unnecessary bits and configuration as we've streamlined the process a bit since the early days.

Comment on pull request references invalid Probot API context function

From:

const params = context.artifact({ body: message })

I get the following error when running a check with commentOnPull: true in the config YML:

14:33:23.105Z ERROR event: context.artifact is not a function (id=ad3a2180-2361-11eb-9aed-b7c419366b46)
  TypeError: context.artifact is not a function
      at RallyValidate.commentOnPull (/tech/appl/default/rally/lib/RallyValidate.js:412:28)
      at RallyValidate.handlePullRequest (/tech/appl/default/rally/lib/RallyValidate.js:184:18)
  --
  event: {
    "event": "pull_request.edited",
    "id": "ad3a2180-2361-11eb-9aed-b7c419366b46",
    "installation": 4,
    "repository": "<org>/<repo>"
  }

Probot documentation does not list this as a valid function for the context object, and Git history shows that it may have been changed from context.issue as part of a search-and-replace commit update.

I believe the correct fix would be to change that line to:

const params = context.pullRequest({ body: message }) 

based on https://probot.github.io/api/latest/classes/context.html#pullrequest but I have not had time to validate that change against all of the payload events.

Duplicate Connections in Rally

Your issue may already be reported!
Please search on the issue tracker before creating one.

Describe the bug
A pull request in GitHub will create links in the Connections tab of the Rally story/defect. If the check is re-triggered, another connection will be created each time. This will happen when changing the title or body of a pull request, or when new commits are pushed to a PR.

To Reproduce
Steps to reproduce the behavior:

  1. Open a pull request with a user story (or valid artifact)
  2. Let the check complete
  3. Change the title or body, or make a new commit
  4. See another connection added in Rally

Expected behavior
A connection is made only when the current PR isn't already linked

Screenshots
2020-08-18_14-47-13

Additional context
Add any other context about the problem here.

Integration ignores workspace value from .env or probot-rally.yml

We have a single service account with access to multiple Rally workspaces.

I tried this in a couple of ways:

  1. Test: Set the workspace OID in the .env file to a valid ID.
    Result: The rally integration uses a different workspace OID to which the account has access.
  2. Test: Set the workspace OID in the probot-rally.yml file to a valid ID.
    Result: The rally integration uses a different workspace OID to which the account has access.
  3. Test: Set the workspace OID in the .env file to 12345
    Result: The rally integration uses a different workspace OID to which the account has access.

It is consistently using the OID for one of our demo workspaces (which we have not set anywhere in the configuration). I am able to successfully validate and pull info on items in this demo workspace, but not on anything else in different workspaces.

The logs validate that it is seeing my configuration changes in either the .env or probot-rally.yml files:

14:01:09.736Z DEBUG probot:
  Final Config: { checksName: 'rally/validator',
    checkPRLabels: false,
    checkPRBody: true,
    checkPRTitle: false,
    checkCommitMessages: false,
    mergeOnPRBody: true,
    rallyProjects:
     [ 'Infrastructure',
       'Sample Project',
       'Test',
       'Onboarding' ],
    rallyObjects: [ 'defect', 'userstory' ],
    artifactStatuses: [ 'Defined', 'In-Progress' ],
    commentOnPull: false,
    rally: { server: 'https://rally1.rallydev.com', workspace: 12345 } }

I am running the latest version of the integration pulled from today (e4f732e5d028e51a3441c6d69da3385832c57c3b)

Initial pending check fails with dynamic checks name

Your issue may already be reported!
Please search on the issue tracker before creating one.

Describe the bug
Dynamically setting the checks name leaves it null for the initial check

22:14:27.686Z ERROR event: Empty value for parameter 'name': undefined (id=3e5d1600-dce9-11ea-82b8-b135190c5ae6)
  HttpError: Empty value for parameter 'name': undefined
      at /opt/rally/node_modules/@octokit/rest/plugins/validate/validate.js:74:15
      at Array.forEach (<anonymous>)
      at /opt/rally/node_modules/@octokit/rest/plugins/validate/validate.js:42:12
      at Array.forEach (<anonymous>)
      at validate (/opt/rally/node_modules/@octokit/rest/plugins/validate/validate.js:15:23)
      at async Job.doExecute (/opt/rally/node_modules/bottleneck/light.js:405:18)
  --
  event: {
    "event": "pull_request.edited",
    "id": "3e5d1600-dce9-11ea-82b8-b135190c5ae6",
    "installation": 6,
    "repository": "GitHub-Demo/probot-rally"
  }
22:14:27.688Z ERROR probot: Empty value for parameter 'name': undefined
  HttpError: Empty value for parameter 'name': undefined
      at /opt/rally/node_modules/@octokit/rest/plugins/validate/validate.js:74:15
      at Array.forEach (<anonymous>)
      at /opt/rally/node_modules/@octokit/rest/plugins/validate/validate.js:42:12
      at Array.forEach (<anonymous>)
      at validate (/opt/rally/node_modules/@octokit/rest/plugins/validate/validate.js:15:23)
      at async Job.doExecute (/opt/rally/node_modules/bottleneck/light.js:405:18)

To Reproduce
Steps to reproduce the behavior:

  1. Create a .github/rally.yml config file with a specific checksName: <name> set
  2. Open a new pull request
  3. Watch the logs
  4. See error

Expected behavior
A check should be created with the name that is defined in the .github/rally.yml

Contributing?

What is the best way to contribute while this repository is private? Forking is disabled and I do not have write access, the contributing docs only mention those two options.

I don't mind submitting feature requests for some of the wish-list items we have, but I could probably also just write some of the features and submit them as PRs.

@primetheus mentioned this would be the best place to bring up any issues or requests for now.

Organization-level configuration for multiple workspaces

Is your feature request related to a problem? Please describe.
Current multi-workspace configuration has to be done per-repository in .github/rally.yml. We use many workspaces across teams and our Rally service account has access to modify state on User Stories for all workspaces. We need a way to manage per-repository configuration in a centralized location in order to avoid developers accidentally misconfiguring their integration. This would be an extension of the existing organization-level configuration.

Describe the solution you'd like
We currently have the following:

If a default configuration for all repositories in an organization is desirable, create a .github/rally.yml file in a repository called [ORG_NAME]/rally-github-config. The name of this configuration repository can also be set as an environment variable.

What I would like is an additional option like this:

If a per-repository configuration centralized at the organization level is desired, create a .github/[REPO_NAME]/rally.yml file in a repository called [ORG_NAME]/rally-github-config.

This would help us centralize configuration of rally workspaces to a single team, rather than ask developers to figure out and configure their own config.

rally.yml "projects" property cannot be omitted (commented out) w/out causing a failure

Describe the bug

rally.yml file contains:

      # Which projects this repo will link to.
      # To have it connect to any project, leave this value blank
      projects:
      #  - Sample Project

If "projects:" is commented out the application will fail with an error (See below) and not process the check.

To Reproduce

  1. Follow standard installation steps for project
  2. When configuring rally.yml comment out the projects: property (and associated values below it),
  3. Start application (I.e. npm start) and monitor output
  4. Issue a commit under repository that application is monitoring
  5. Watch for error and check failure.

Expected behavior
If "projects:" yml configuration is commented out the application should not fail, but still communicate with Rally (ignoring specific project).

9:12:20.665Z ERROR event: Cannot read property 'map' of undefined (id=bbbfd500-e186-11ea-99fc-f0362d48b04c)
  TypeError: Cannot read property 'map' of undefined
      at RallyValidate.processArtifacts (/opt/gitrallyapp/lib/RallyValidate.js:255:56)
      at RallyValidate.handlePullRequest (/opt/gitrallyapp/lib/RallyValidate.js:171:53)
  --
  event: {
    "event": "pull_request.edited",
    "id": "bbbfd500-e186-11ea-99fc-f0362d48b04c",
    "installation": 291,
    "repository": "ESD/DA"
  }
19:12:20.665Z ERROR probot: Cannot read property 'map' of undefined
  TypeError: Cannot read property 'map' of undefined
      at RallyValidate.processArtifacts (/opt/gitrallyapp/lib/RallyValidate.js:255:56)
      at RallyValidate.handlePullRequest (/opt/gitrallyapp/lib/RallyValidate.js:171:53)
19:12:20.665Z  INFO http: POST / 500 - 1373.21 ms (id=bbbfd500-e186-11ea-99fc-f0362d48b04c)
19:12:20.665Z TRACE http:  (id=bbbfd500-e186-11ea-99fc-f0362d48b04c, res.duration=1373.21)
  HTTP/1.1 500 Internal Server Error
  x-powered-by: Express
  x-request-id: bbbfd500-e186-11ea-99fc-f0362d48b04c

Blog Post

@migarjo @primetheus

For the open source process of this repo, we need to write a blog post for github.blog. Since you two are the top contributors on this project, can you help me out in one of two ways?

  • Volunteer to write the blog post announcing the new open source project
  • Get me the details of value of this project and reason why we created this and I can write up the blog post and get your review

Many of the other issues related to open sourcing this are closed out and this is one of the last large items (from my perspective) to take care of.

Document Rally Permissions

Our testing has been using a Workspace Admin account in order to test, but in production environments this will not be the case. We will need to document the required permissions in Rally for this application to run

probot-rally project name

I noticed on the GitHub marketplace that it is not a standard convention to have "probot" in the name of an app that uses probot.

I'm wondering if a different name would be more suitable for this project before we open source it and potentially release it to the marketplace.

Some ideas:

  • Rally
  • Rally Bot
  • Rally Integration
  • Rally Sync
  • Rally Artifact Sync
  • Rally Validator
  • Rally Inspector
  • Rally State Sync
  • Rally Artifact Updater
  • Rally Intelligence

Any other ideas? Want to stick with probot-rally? Comment with your thoughts.

cc/ @github/services-devops-engineers

Deployment

Should this repository be published to npm when it is released? Would that make things easier for the user?

If not let's close this issue.

If it would be helpful, lets automate it and add it to the release instructions in CONTRIBUTING.

License not reported by GitHub UI

Your issue may already be reported!
Please search on the issue tracker before creating one.

Describe the bug
The GitHub UI does not report that the project has a license.

To Reproduce
Steps to reproduce the behavior:

  1. Go to github.com/github
  2. Search for rally
  3. Observe that no license is reported in the metadata below the repo

Screen Shot 2020-08-13 at 5 02 50 PM

also

  1. Go to github.com/github/rally
  2. Observe that in the right side panel no license is reported

Screen Shot 2020-08-13 at 5 01 34 PM

Expected behavior
The GitHub UI should detect and report the license and its type
Screen Shot 2020-08-13 at 4 57 48 PM
Screen Shot 2020-08-13 at 5 03 20 PM

Screenshots
see inline above

Additional context
It was moved from the repo root directory to the .github/ at a9825af but I'm not sure for what reason.

Feature: Support for OAuth Credentials

In order to help secure the application and enable better integrations, OAuth credentials can be created within Rally. This would replace and deprecate the username/password functionality, as that is insecure

Invalid artifacts have `undefined` as icon

Your issue may already be reported!
Please search on the issue tracker before creating one.

Describe the bug

Artifacts that don't exist in Rally should have โ— by the status. Instead, they have "undefined".

To Reproduce

Steps to reproduce the behavior:

  1. Open a pull request
  2. Add a user story that does not exist in Rally
  3. Check the status of the app

Screenshots

Expected:
2020-08-12_9-47-55

Actual:
2020-08-12_9-48-55

Integration for Commits

In Our project we use GIT Flow as branching strategy and commits are done to different branches as per development cycle. Since for a Rally User Story Id there will be commits to multiple branches does this connector provide details of GIT commits on Rally for all branches?

Consolidate rally config items

The present YAML file contains the following:

rallyProjects: ['Sample Project', 'devops-engineering']
rallyObjects: ['defect', 'userstory']
artifactStatuses: ['Defined', 'In-Progress']
rally:
  server: https://rally1.rallydev.com
  #username: me
  #password: pass
  #api_key: key
  workspace: 12345

It would be better for organization to consolidate them into the following:

rally:
  server: https://rally1.rallydev.com
  #username: me
  #password: pass
  #api_key: key
  workspace: 12345
  projects:
    - Sample Project
    - devops-engineering
  objects:
    - defect
    - userstory
  states:
    - Defined
    - In-Progress

Limitations list

Are there any limitations of this app that should be listed after the feathers in the README.md

multiple commit messages

Your issue may already be reported!
Please search on the issue tracker before creating one.

Describe the bug
If a pull request has multiple commits/commit messages , the check fails to run

To Reproduce
Steps to reproduce the behavior:

  1. Create a PR
  2. rally.yml must have the commit message validation checked
  3. Click on the checks
  4. Checks does not run when PR has multiple commit messages

Expected behavior
Checks must be run for all commit messages

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Expand validation to check fields other than Schedule State

Is your feature request related to a problem? Please describe.
This integration is currently hard-coded to validate only against the Schedule State of a Rally artifact. There are other use-cases that require validation of other fields in Rally (like State). This is particularly true of Test Cases, which do not have a Schedule State attribute

Describe the solution you'd like
Rather than only checking against the Schedule State attribute, this integration should allow for configuration to check any rally attribute available via the API. Since some attributes are specific to certain artifact types (i.e. Tasks, Defects, Test Cases), the configuration should be able to apply different logic to different artifacts

Add JSDoc

Add JSDoc comments for auto-generated documentation

Feature: Remove support for label validation

Labels provide a quick functionality test, but provides no production value. Using this in production would result in thousands of labels being created within each repository, which is not the desired result

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.