The jiralint from agiledigital

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions

.github/workflows/build-test-release.yml

actions/checkout v3

actions/setup-node v3

actions/cache v3

npm

cli/package.json

clear 0.1.0

clui 0.3.6

colors 1.4.0

date-fns 2.29.3

fp-ts 2.13.1

inquirer 8.2.4

io-ts 2.2.20

io-ts-types 0.5.19

monocle-ts 2.3.13

newtype-ts 0.3.5

oauth 0.10.0

readonly-types 4.5.0

string-length 4.0.2

ts-pattern 4.2.1

yargs 17.5.1

@types/clear 0.1.2

@types/clui 0.3.1

@types/inquirer 7.3.3

@types/jest 29.4.0

@types/oauth 0.9.1

@typescript-eslint/eslint-plugin 5.54.1

@typescript-eslint/parser 5.54.1

eslint 8.35.0

eslint-config-agile-digital ^2.6.0

eslint-config-prettier 8.7.0

eslint-config-typed-fp 4.4.0

eslint-plugin-functional 5.0.5

eslint-plugin-jest 27.2.1

eslint-plugin-prettier 4.2.1

eslint-plugin-sonarjs 0.18.0

eslint-plugin-total-functions 6.3.0

jest 29.5.0

prettier 2.8.4

rollup 2.79.0

rollup-plugin-cleanup 3.2.1

rollup-plugin-delete 2.0.0

rollup-plugin-typescript2 0.33.0

ts-jest 29.0.5

tsconfig-paths-webpack-plugin 4.0.0

type-coverage 2.24.1

typescript 4.9.5

node >=10

lib/package.json

colors ^1.4.0

date-fns ^2.29.3

fp-ts ^2.13.1

io-ts ^2.2.20

io-ts-types ^0.5.19

jira-client ^6.21.1

monocle-ts ^2.3.13

newtype-ts ^0.3.5

oauth ^0.10.0

readonly-types ^4.5.0

ts-pattern ^3.2.2

io-ts-reporters 2.0.1

@semantic-release/git 9.0.1

@types/jest 29.4.0

@types/jira-client 6.21.3

@types/oauth 0.9.1

@typescript-eslint/eslint-plugin 5.54.1

@typescript-eslint/parser 5.54.1

eslint 8.35.0

eslint-config-agile-digital ^2.6.0

eslint-config-prettier 8.7.0

eslint-config-typed-fp 4.4.0

eslint-plugin-functional 5.0.5

eslint-plugin-jest 27.2.1

eslint-plugin-prettier 4.2.1

eslint-plugin-sonarjs 0.18.0

eslint-plugin-total-functions 6.3.0

jest 29.5.0

prettier 2.8.4

semantic-release 19.0.5

ts-jest 29.0.5

type-coverage 2.24.1

typescript 4.9.5

ts-essentials 9.3.1

node >=10

package.json

io-ts-reporters ^2.0.1

semantic-release 19.0.5

ts-node ^10.9.1

@commitlint/cli 13.2.1

@commitlint/config-conventional 13.2.0

commitizen 4.3.0

cz-conventional-changelog 3.3.0

eslint-config-agile-digital ^2.6.0

fast-check 3.7.1

husky 7.0.4

node >=10

nvm

.nvmrc

node 16.17

Check this box to trigger a request for Renovate to run again on this repository

chore: Set min test coverage numbers

new rule: heavier penalisation for tickets stalled more than 1w

Publish lib package to GPR automatically

Now that jiralint-pulumi is consuming the lib package from this repo via a true npm package (private; Github Package Registry), it would be good to automatically publish that package upon release of this repo (via github action, probably).

This will probably involve:

in the CI github action: publish the npm package. The ambient GITHUB_TOKEN should give you permission to do this. The action at https://github.com/cycjimmy/semantic-release-action looks promising for this. If that action doesn't work, fall back on doingnpm publish manually (https://docs.npmjs.com/cli/v6/commands/npm-publish). Ensure you're publishing to the private Github Package Registry associated with this repo, not the public npm registry
do the above step only for main branch and/or only for release tags

If that doesn't work, we may have to use a machine user and a corresponding PAT:

provision a machine user (https://docs.github.com/en/developers/overview/managing-deploy-keys)
crete a PAT for that machine user that is permitted to publish packages (https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token)
store that PAT in a github secret for this repo (https://github.com/agiledigital-labs/jiralint/settings/secrets/actions)
in the CI github action: move that PAT where it needs to be so npm publish uses it (cf. https://github.com/agiledigital-labs/jiralint-pulumi/blob/main/.github/workflows/build-test.yml#L28)
then as above

chore: add Stryker

Review command line arguments for grouping and env var support

New rule: Dependencies should not be near to or past their due date without being resolved

Flag 'old' Reopened issues

chore: prevent circular dependencies between workspaces

We want to break the build if:

a) the lib package is made to depend on the cli package
b) circular package dependencies are introduced in general

This might be the answer: https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-cycle.md

feat: port https://github.com/agiledigital-labs/probabilistic-forecast here

Command line arg parsing is broken?

At some point we introduced a .jiralintrc config file. This is cool, but I think we've accidentally broken the (now rarely used?) old command line version of the same options.

Even when I specify the host using -h or --jira.host, I still get:

Missing required arguments: jira.host, jira.consumerSecret

swap from npm install to npm ci in build job

Use same node version across CI and local nvm

Currently one is 15 and the other is 16

Ensure that worklogs on subtasks are used when determining whether time has been logged recently

New rule: enforce story point implications

feat: assign a score of `N/A` during grace period

new rule: tickets should not be waiting for review for too long

Plug in nvm

In a step toward reproducible builds (or at least, less irrepreducible), we should set up an nvmrc file to try to get all devs aligned on the same node version.

https://github.com/nvm-sh/nvm

https://github.com/nvm-sh/nvm#nvmrc

Set up husky

chore: restore dynamic `require` of CLI scripts

This dynamic require interacted badly with rollup and/or TypeScript, so I ripped it out and replaced it with explicit imports and function calls.

new rule: tickets with an assigned release version should not be in progress X days before release

Add CI build

build, lint, and test action
semantic release to save dist bundle to github

Use Jira Expressions

Evaluate the use of Jira Expressions instead of the current approach to fetch the data.

v3 of the plain REST APIs store descriptions as structured JSON objects instead of wikitext, so eventually a different approach (like Jira Expressions) will be necessary.

Tweak description rule

Some projects use custom description fields so that templates can be used.

Permit configuration of those description fields (a map of type -> custom field(s)) and check those as well.

New rule: issues shouldn't transition too much

New rule: Dependencies should have a due date

Tweak rule: Dependencies should not need worklogs or estimates

Allow jiraHost, jiraProtocol, etc to be overridden via CLI args

Would make usage on client Jiras, etc much easier

Enforce commit message standards in server side git hook

New rule: no estimate should be more than three days.

Use better auth mechanism

Use the same approach as denim to authenticate.

Support for 'cloud' Jira.

jiralint currently only support on-prem Jira ("Jira Server"). We want to continue to benefit from it as we migrate to Jira Cloud.

Recent worklog fix is broken

IPASIP-2436 can not be parsed

Failed to decode issues [[\"Invalid value null supplied to : Readonly<Array<({ key: string, self: string, fields: ({ summary: string, description: fromNullable((string | undefined)), created: ReadonlyDate from ISO string, project: { key: string }, timetracking: fromNullable(Partial<{ originalEstimateSeconds: number, timeSpentSeconds: number, remainingEstimateSeconds: number, originalEstimate: string, timeSpent: string }>), fixVersions: ReadonlyArray<{ id: string, name: string, released: boolean }>, aggregateprogress: { progress: fromNullable((number | undefined)), total: fromNullable((number | undefined)), percent: fromNullable((number | undefined)) }, issuetype: { name: string, subtask: boolean }, status: { id: string, name: string, statusCategory: { id: fromNullable((number | undefined)), name: fromNullable((string | undefined)), colorName: fromNullable((string | undefined)) } }, comment: fromNullable((Readonly<(Readonly<{ maxResults: number, total: number, startAt: number }> & { comments: ReadonlyArray<{ id: string, author: fromNullable(({ name: fromNullable((string | undefined)) } | undefined)), body: string, created: ReadonlyDate from ISO string, updated: ReadonlyDate from ISO string }> })> | undefined)), worklog: fromNullable((Readonly<(Readonly<{ maxResults: number, total: number, startAt: number }> & { worklogs: ReadonlyArray<{ author: { name: fromNullable((string | undefined)) }, started: ReadonlyDate from ISO string, timeSpentSeconds: number, comment: fromNullable((string | undefined)) }> })> | undefined)), duedate: fromNullable((DateFromISOString | undefined)) } & Partial<{ aggregatetimeestimate: fromNullable((number | undefined)), aggregatetimeoriginalestimate: fromNullable((number | undefined)), aggregatetimespent: fromNullable((number | undefined)), parent: { id: string, key: string } }> & Readonly<{ [K in string]: unknown }>), changelog: fromNullable({ histories: ReadonlyArray<{ id: string, author: { name: fromNullable((string | undefined)) }, created: ReadonlyDate from ISO string, items: ReadonlyArray<{ field: string, fieldtype: string, from: (string | null), fromString: (string | null), to: (string | null), toString: (string | null) }> }> }) } & { fields: { assignee: { accountId: string, displayName: string } } })>>/0: ({ key: string, self: string, fields: ({ summary: string, description: fromNullable((string | undefined)), created: ReadonlyDate from ISO string, project: { key: string }, timetracking: fromNullable(Partial<{ originalEstimateSeconds: number, timeSpentSeconds: number, remainingEstimateSeconds: number, originalEstimate: string, timeSpent: string }>), fixVersions: ReadonlyArray<{ id: string, name: string, released: boolean }>, aggregateprogress: { progress: fromNullable((number | undefined)), total: fromNullable((number | undefined)), percent: fromNullable((number | undefined)) }, issuetype: { name: string, subtask: boolean }, status: { id: string, name: string, statusCategory: { id: fromNullable((number | undefined)), name: fromNullable((string | undefined)), colorName: fromNullable((string | undefined)) } }, comment: fromNullable((Readonly<(Readonly<{ maxResults: number, total: number, startAt: number }> & { comments: ReadonlyArray<{ id: string, author: fromNullable(({ name: fromNullable((string | undefined)) } | undefined)), body: string, created: ReadonlyDate from ISO string, updated: ReadonlyDate from ISO string }> })> | undefined)), worklog: fromNullable((Readonly<(Readonly<{ maxResults: number, total: number, startAt: number }> & { worklogs: ReadonlyArray<{ author: { name: fromNullable((string | undefined)) }, started: ReadonlyDate from ISO string, timeSpentSeconds: number, comment: fromNullable((string | undefined)) }> })> | undefined)), duedate: fromNullable((DateFromISOString | undefined)) } & Partial<{ aggregatetimeestimate: fromNullable((number | undefined)), aggregatetimeoriginalestimate: fromNullable((number | undefined)), aggregatetimespent: fromNullable((number | undefined)), parent: { id: string, key: string } }> & Readonly<{ [K in string]: unknown }>), changelog: fromNullable({ histories: ReadonlyArray<{ id: string, author: { name: fromNullable((string | undefined)) }, created: ReadonlyDate from ISO string, items: ReadonlyArray<{ field: string, fieldtype: string, from: (string | null), fromString: (string | null), to: (string | null), toString: (string | null) }> }> }) } & { fields: { assignee: { accountId: string, displayName: string } } })/1: { fields: { assignee: { accountId: string, displayName: string } } }/fields: { assignee: { accountId: string, displayName: string } }/assignee

feat: define some simple checks for individuals

Some ideas:

the lint issues for any tickets that the individuals 'owns' that are being 'worked'
number of issues being worked by the individual
hours logged last business day
hours logged this pay period vs expected hours logged this pay period

New rule: in progress tickets should be worked

Add a new rule that will fail if an In Progress not stalled ticket hasn't been worked (as evidenced) by a worklog in the last business day.

New rule: comment added within X hours of worklog

Our current comment checking rule requires a comment if:

time has been logged AND the issue isn't closed
OR the issue is in progress

A conceptually simpler rule is to require a comment whenever time has been logged. i.e a comment must be added "around" the same time that a worklog is added.

The check would look at:

time of most recent worklog
time of most recent comment

the rule would pass if the comment was <1d before the worklog or after it.

What makes it non-trivial is that worklogs and comments are both paginated fields, so they may be truncated. Issues are currently retrieved using the search API. We need to do one of:

see if those fields can be sorted so that we always get the most recent comment and worklog
check search results and (if necessary) pull individual ticket comments and worklogs

agiledigital / jiralint Goto Github PK

jiralint's People

Contributors

Stargazers

Watchers

Forkers

jiralint's Issues

Rate-Limited

Open

Detected dependencies

Recommend Projects

Recommend Topics

Recommend Org