fix for parallel mode, flag_name & base_path

[johanneswilm]

This adds two new options (flag_name and base_path) that work the same way as they do in the main coveralls action and it fixes the calculation of the reference that is being used in the parallel_finished call.

[marvin-w]

@AndreMiras Without this PR this action is kind of not usable.

@johanneswilm Tested successfully. Thank you!

[AndreMiras]

Very nice job @johanneswilm!
Thanks for looking into it and thanks for updating tests as well.

I see some tests of this PR are failing because of PR restricted access to GITHUB_TOKEN from PR. I haven't thought about that one, but I think the changes look good still.
For records, the error was:

Running on Github Actions but GITHUB_TOKEN is not set.
Add "env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}" to your step config.

I need to think of a remedy for next time (suggestions welcomed).

Note, for future PR maybe try to squash your commits to keep neat commit log.
Luckily I can squash it upon merge, but I'd rather have it already tidied up in the PR itself

[AndreMiras]

We got a regression on the COVERALLS_REPO_TOKEN feature after merging this.
The error is:

Trying submitting coverage with service_name: github...
'service_job_id'
ExitCode.FAILURE

Error details:
https://github.com/AndreMiras/coveralls-python-action/runs/1468738734
@johanneswilm any idea why this is happening?

[johanneswilm]

I guess if you use the COVERALLS_REPO_TOKEN rather than the GITHUB_REPO_TOKEN then the job id is calculated differently? If supporting that is important to you, maybe try to reinstate the old way of calculating the job id (that wasn't working with the GITHUB_REPO_TOKEN).

[johanneswilm]

@AndreMiras You probably need to create another option --coveralls-token to be able to distinguish between the two. Sorry, I didn't get that you actually wanted to use the coveralls token.

[AndreMiras]

I started looking into it and yes your changes may not be related to this feature being broken, but maybe to an API change on their side.
Yes I'll probably look into this explicit option see if it helps. Will check that a bit later, thanks
Edit:
It's something that started to happen with the upgrade from coveralls==2.1.2 to coveralls==2.2.0.
Will debug from there

[AndreMiras]

Fixed via 50af55e

[AndreMiras]

Made some follow up refactoring changing the default of the two flags you introduced. I hope I didn't introduce any bugs I haven't integration tested.
Basically it was bugging me to have the default being a boolean (False) for a value that could take a string at the end. So I got the default a bit more type consistent