leonardowf / baroneza Goto Github PK

When creating a release on Jira, it would be interesting to support a suffix to identify a specific component.
For example, a Jira project may contain several components, a web project, a backend project.

The idea is to create a release named: "1.0.10 Backend" or "1.0.10 Web" etc...

It would be nice if baroneza had an endpoint to check if the provided token and config are valid.

As tokens expire or get expired, it is kind of annoying to discover that something stopped working the moment what you have to use it.

Also, after updating the tokens to the correct ones, there is no easy way to tell if they indeed work for a repository or jira organization for example.

So, with this, baroneza should tell through an /health?repo="readable-repo"&jira-org="readable-org" if the dependencies are up and running.

There is a flaky scenario in the update release endpoint:

When a release is updated and a new ticket from a Jira board that does not have a release is called, looks like the entire changelog enters as new [Needs investigation]

It would be nice if baroneza created the release when updating. This could be configured through a parameter.

When running updateRelease command to update an existing release the following error message is shown:
Cannot Unable to find JIRA release named XXXXX
The command looks like this:
curl --location --request POST 'ip/updateRelease' \ --header 'Content-Type: application/json' \ --data-raw '{ "channel": “channel-“name, "fromVersion": “x.xx.xx, "jiraSuffix": " Android", "projectKeys": [“PR1, “PR2”, “PR3”], "pullRequestNumber": 1111, "repository": “repo-name”, "title": “Release “name, "toVersion": “x.xx.xx” }'

Context:

Sometimes, tickets that are in a fix-version release of Jira are not moved to the final state of "Verified" before the release is closed.

This can be problematic for a number of reasons:

• Tickets that are not marked as "Verified" create confusion if they were QA'd
• Tickets that are not marked as "Verified" create confusion if they are ready for release
• Tickets that are not marked as "Verified" are not closed automatically when the release is closed.
• Tickets that are not marked as "Verified" impact bookeeping of the release

Solution:

It would be nice if there was an endpoint that could be called to list all tickets that are in a fix-version release that are not in the "Verified" state.
This could be done per project, and per release.

Example:

POST /releaseStatus
Body:

{
  "projectKeys": ["ABC", "DEF"],
}

Response:

{
    "releases": [
        {
            "projectKey": "ABC",
            "releaseName": "1.0.0",
            "tickets": [
                {
                    "key": "ABC-123",
                    "summary": "This is a ticket",
                    "status": "In Progress"
                },
                {
                    "key": "ABC-456",
                    "summary": "This is another ticket",
                    "status": "In Progress"
                }
            ]
        },
        {
            "projectKey": "DEF",
            "releaseName": "1.0.0",
            "tickets": [
                {
                    "key": "DEF-123",
                    "summary": "This is a ticket",
                    "status": "In Progress"
                },
                {
                    "key": "DEF-456",
                    "summary": "This is another ticket",
                    "status": "In Progress"
                }
            ]
        },
                {
            "projectKey": "DEF",
            "releaseName": "1.0.0",
            "tickets": [
                {
                    "key": "DEF-123",
                    "summary": "This is a ticket",
                    "status": "In Progress"
                },
                {
                    "key": "DEF-456",
                    "summary": "This is another ticket",
                    "status": "Ready for Test"
                }
            ]
        }
    ]
}

Additionally it would be nice if there was a way to filter the results by the status of the ticket. For example, if I only wanted to see tickets that were in the "In Progress" state.

POST:
/releaseStatus
BODY:

{
    "projectKeys": ["ABC", "DEF"],
    "statuses": ["In Progress", "Ready for Test", "Backlog"]
}

Response:

{
    "releases": [
        {
            "projectKey": "ABC",
            "releaseName": "1.0.0",
            "tickets": [
                {
                    "key": "ABC-123",
                    "summary": "This is a ticket",
                    "status": "In Progress"
                },
                {
                    "key": "ABC-456",
                    "summary": "This is another ticket",
                    "status": "In Progress"
                }
            ]
        },
        {
            "projectKey": "DEF",
            "releaseName": "1.0.0",
            "tickets": [
                {
                    "key": "DEF-123",
                    "summary": "This is a ticket",
                    "status": "In Progress"
                },
                {
                    "key": "DEF-456",
                    "summary": "This is another ticket",
                    "status": "Ready for Test"
                }
            ]
        },
                {
            "projectKey": "DEF",
            "releaseName": "1.0.0",
            "tickets": [
                {
                    "key": "DEF-123",
                    "summary": "This is a ticket",
                    "status": "In Progress"
                },
                {
                    "key": "DEF-456",
                    "summary": "This is another ticket",
                    "status": "Backlog"
                }
            ]
        }
    ]
}

IWBNI:

• We fetched all the tickets in a release
• Read individually the sprint of the tickets
• Decided based on a substring rule to which owner that ticket would be assigned to.

The real-life scenario is:

• After we cut a release
• We want to assign to the QA the tickets that were worked on based on the sprint of the team that worked on it

Right now, guessing the next release uses the last PR that has a semver.

But if you have any PR, that has semver, then it picks that version.

The ideal solution would be to use the tag of the repo

Slack does not support titles in the format ###
Making the changelog look weird.

It would be nice to reformat it to make it appear nicer

It would be nice to get some data from the current open releases just by providing a repository name.

For example,
GET /release?repo=repo-name&prefix=releases%2F2.5.4

Would return something like:

{
    "pullRequest": {
        "number": 123,
        "title": "The title of the pull request",
        "description": "The description of the pull request",
        "targetBranch": "master",
        "baseBranch": "release-2.5.4"
    },
    "jira": {
        "tickets": [
            { "id": "ABC-123", "status": "In Progress" }
        ]
    },
    "baroneza": {
        "branchPrefix": "release-",
        "semver": "2.5.4"
    }
}

In case of multiple releases found, the newest should be returned.

When there is already a release branch open, developers usually commit bug fixes and last-minute changes.

Those commits/tickets can be lost due to tagging being used only at the start of the release.

It would be cool if the tagging, milestone, and changelog would be regenerated, updated, and notified again for an open branch.

Github just launched as experimental a nice tool to find code vulns,
It would be nice, if possible to enable it and get these reports here

https://github.blog/2022-02-17-code-scanning-finds-vulnerabilities-using-machine-learning/

Sometimes GitHub adds URL at the end of pull requests, this enters changelogs.

It would be nice if baroneza picked up only - entries

IWBNI Baroneza when fetching commits from both a branch or a list of shas, picked up the entire commits and not only the first page.

See: #157
See: https://github.com/leonardowf/baroneza/blob/master/src/workers/commit-extractor.ts
See: https://github.com/leonardowf/baroneza/blob/master/src/services/github-service.ts#L446

It would be nice if the application did not crash completely when we invoke an endpoint with an invalid project key.

Edit: The issue is caused by eager x lazy conversion of promise to rxjs

Reference: https://stackoverflow.com/questions/39319279/convert-promise-to-observable/69360357#69360357

Reference: https://blog.heroku.com/best-practices-nodejs-errors

Sometimes a pull request addresses multiple Jira tickets and it would be nice to be able to identify all the tickets from said PR.

For example, a PR that closes two Jira tickets generates the commit message in the format:

"[JIR-123] [JIR-456] Fixes lots of bugs"

The tickets are JIR-123 and JIR-456

The release train currently implemented (/startTrain) asks for positive confirmation before continuing.

It would be nice if the dispatched train checked instead for cancellation requests, like a stop 🛑 break.

The following diagram illustrates the idea

TSError: ⨯ Unable to compile TypeScript:
src/app.ts:48:18 - error TS2769: No overload matches this call.
  The last overload gave the following error.
    Argument of type '(err: any) => void' is not assignable to parameter of type '() => void'.

48 app.listen(port, (err) => {
                    ~~~~~~~~~~

  node_modules/@types/express-serve-static-core/index.d.ts:1126:5
    1126     listen(handle: any, listeningListener?: () => void): http.Server;
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The last overload is declared here.
src/app.ts:48:19 - error TS7006: Parameter 'err' implicitly has an 'any' type.

48 app.listen(port, (err) => {
                     ~~~

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: `node --inspect=5858 -r ts-node/register ./src/app.ts`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/sanuk/.npm/_logs/2021-02-06T18_21_12_847Z-debug.log
[nodemon] app crashed - waiting for file changes before starting..

For some reason on my machine I can compile use-strict, but on others, it does not work 👎
Server works fine removing use-strict