Skip to content

Conversation

@ped7g
Copy link

@ped7g ped7g commented Jul 23, 2019

Goal of this pull request:
to collect comments/ideas/criticism from actual python coders

As I'm not python programmer myself, and not an CI expert either, I hacked this to get away from being stuck at "Build #1" at my project, using Cirrus CI.

Not sure if anything of this is general enough to be pulled into main version, or if I wrote it in a very non-python way, let me know if you have some thoughts about this (but it "WFM" at this moment).

If somebody else want to reuse this kind of hack, keep in mind the revision-counter from git is very flaky value, susceptible to git log history edits, etc.. For me personally this is "good enough", as I don't care too much if I will lose by accident coverage history, but if you need something more solid, it seems to me the least friction path is to just simply add also Travis CI to your project, and use the coveralls native support of it.

ped7g added 3 commits July 22, 2019 17:21
If the service_name + service_job_id is not set to identify build, the
default build numbers auto-incremented by coveralls.io seems to never
advance (doing just incremental changes to original build eddyxu#1), so this
git revision number hack is used to get something more meaningful (at
least at the project I'm trying to make this work, it's acting like
this, numbering coverage data 1.1, 1.2, 1.3,.. and staying at Build eddyxu#1
for every commit, even when sources did change)

This may be inherently wrong solution and complete hack, feel free to
comment+help with the issue (also I don't know python, so the code
change may be not optimal itself).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant