Properly handle pagination of job and took

[tchssk]

Related to #185

GitHub REST API pagination do not return all results at once but instead return the first 30 items by default.
Therefore action-slack shows Job is not found when it be used with workflows including 31 jobs or more.

This pull request fix the problem by using paginate of octokit.

[8398a7]

https://github.com/octokit/plugin-paginate-rest.js

Does this modification refer to all jobs when retrieving one job?
If all jobs are requested even if the expected job is found along the way, the processing time will be very long.

const issues = await octokit.paginate(
  "GET /repos/{owner}/{repo}/issues",
  {
    owner: "octocat",
    repo: "hello-world",
    since: "2010-10-01",
    per_page: 100,
  },
  (response, done) => {
    if (response.data.find((issue) => issue.title.includes("something"))) {
      done();
    }
    return response.data;
  }
);

It seems possible to abort the process when the expected data is returned. Is this appropriate for our requirements?

[tchssk]

Thank you for pointing it out.
It looks good to me. I changed to use the response map function. 88c313b

[codecov]

Codecov Report

Merging #225 (88c313b) into master (e080ee3) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #225   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            2         2           
  Lines          238       246    +8     
  Branches        77        79    +2     
=========================================
+ Hits           238       246    +8     

Impacted Files	Coverage Δ
src/fields.ts	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.