-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fall back to current time if git metadata is not available #192
Conversation
Hey @marcinwyszynski, Our new test reporter supports a number of environment variables for the commited at timestamp:
You can find the docs for the new test reporter here: https://docs.codeclimate.com/docs/test-reporter Alternatively, you could mount the
I would recommend checking out the new test reporter. Hopefully one of these solutions works for you. Let me know! |
Thanks @dblandin, either of your suggestions will work. Still, this looks like a decent fallback? |
I'm not necessarily against having this defaulting client-side, but this value is not a required attribute in the payload and we will default to "now" when we receive it server-side. |
@pbrisbin That's not what I've seen. First, |
In similar vein, the new test reporter would still fail in my scenario, except if I manually added a dummy timestamp variable (since CircleCI does not expose it). If that value is optional and not required on your end, perhaps let's not make it required in either reporter? |
I'm sorry @marcinwyszynski, I must've been incorrect (or out of date). I'll leave the decision to accept this patch (and push it through to a release) to another teammate. Given that the old reporters are very near deprecated, if we do want this defaulting, we might want to do it only in the new test-reporter codebase. |
I'm hesitant to accept this patch if solutions exist that will pass along the correct value. The current time might be close but does not accurately reflect when the commit was committed. The committed at timestamp is important today when we're deciding whether to render test coverage annotations on github.com via the browser extension. We likely use this timestamp on codeclimate.com as well. I think it's probably better to encourage reporting with the correct data. I can think of a few cases that might lead to non-trivial drifts between the real committed at time and What if a CI run is rebuilt? I'd personally rather error with a meaningful message, leading to an approach that will send the right data. For Circle CI specifically, until they have an environment variable to thread through, volume-mounting the @marcinwyszynski What do you think? |
Mounting |
Yep, definitely not ideal but I think it's better than allowing inaccurate data through. I'll reach out to Circle CI to see if they might add a Thanks for the discussion! 👍 |
@dblandin Unfortunately I'll have to reopen it because volume mounting does not work in Circle CI. |
This change makes coverage reporting work from a Docker container built in CI with no
git
metadata (as this is not something you want persisted in your Docker image). I believe that current timestamp is a decent fallback value, since you'd usually run coverage reporter from a CI provider which is triggered by a commit. An alternative I think would be to allow passing commit timestamp as an environment variable.