Build steps reflected incorrectly in log output

[kriegaex]

I just installed the plugin 5 minutes ago for the first time. Drilling down into the log of one of my build jobs, I noticed this:

While the reality looks more like this:

For reference, this is the Maven build I am inspecting: https://github.com/kriegaex/Asciidoctor_HTMLContainsCRLFOnWindows/actions/runs/7946420025

[cunla]

thanks for bringing it up. this is a change implemented in the last version.

I will work on it.

[cunla]

I looked. There are inaccuracies which I addressed in #110.

However, looking at the results coming from github API: https://api.github.com/repos/kriegaex/Asciidoctor_HTMLContainsCRLFOnWindows/actions/runs/7946420025/jobs returns step 4 (Run Maven Build) time:

{
      "name": "Run Maven Build",
      "status": "completed",
      "conclusion": "success",
      "number": 4,
      "started_at": "2024-02-18T03:59:37.000Z",
      "completed_at": "2024-02-18T03:59:50.000Z"
  },

While if you download the logs of the job (From here: https://github.com/kriegaex/Asciidoctor_HTMLContainsCRLFOnWindows/actions/runs/7946420025/job/21694126031) - The step finishes much later.

I addressed it using some heuristics, but it is not possible to be 100% since the information coming from github API is not accurate.

[kriegaex]

Please create an issue with GitHub, which we then can watch. A heuristic workaround does not solve the problem.

[cunla]

I would appreciate if you create an issue with GitHub and link here.

[kriegaex]

You are the maintainer of this plugin. You are the user who can describe how he uses the API and what the exact problem is. My report would be second-hand and sketchy at best. I suggest, you take responsibility.

[cunla]

As the author and maintainer of this plugin, I find that a heuristic workaround solve the problem properly.

I appreciate you raising issues and I am addressing any issue promptly. However, I also decide how to address the issue. If you believe there is a better way (eg, opening a bug on GitHub) - please, do so and do not order authors/maintainers what steps to take.

I suggest you be more respectful towards open-source authors/maintainers. Take responsibility over ensuring the plugin continues to be maintained and developed - appreciate open-source contributors!

I see this issue as closed.

[kriegaex]

Maybe you had a difficult day, so I am going to give you the benefit of the doubt. Let me try again:

Firstly, I did not order you to do anything, I used the term suggest. I hope, it is not beneath you that a user of your software makes a suggestion. Being a maintainer of some bigger and smaller OSS projects myself and contributor to many, I am talking as a peer to you who knows how OSS development works. We all do this for free in our spare time. But still, my mindset is that as a maintainer, you have certain responsibilities, and as someone reporting an issue you do, too.

A reporter needs to explain the issue in enough detail for the maintainer to understand and reproduce it. The reporter also should answer follow-up questions and after a fix or a new feature implementation re-test his issue.

A maintainer, however, should not just fix the problem somehow, however adequate, but if he claims that there is an upstream problem in a library, API or service he is using, he ought to take the role of user and reporter there and open an issue, add a to-do comment to his software at the location of the workaround and strive to fix it in a clean way after the upstream issue has been resolved. I always do that when I encounter such problems. I have opened issues in many libraries, fixed some of them myself and even went as far as reporting JDK bugs.

What I am saying is that your fix is probably working great, I did not have any chance to re-test it yet, waiting for the next IDEA plugin update. Nowhere did I say that your change is bad or inadequate. What I did say is that, if it is true what you said about the GitHub API returning data inconsistent with the job step timestamps, your change is a (potentially brittle or unstable) workaround. A conclusive, stable fix would be preferable, but for that you need to report your problem to GitHub and convince them to improve their API. Never having used said API myself, I am the wrong person to do that. I also do not know your code and how you use that API.

[kriegaex]

Back to the issue at hand, I want to ask a question: Are you aware of the "Download log archive" web UI feature?

It is not as fine-granular as the API where you can download a log per job, but OTOH it is more fine-granular at the same time, because in the archive there are segmented logs for each job of a workflow run, conveniently split by workflow step:

I have no idea if this function is exposed by the GitHub API - probably not, otherwise you would probably be using it already - but it clearly demonstrates that the functionality we need here exists somewhere at GitHub, and it could be exposed as an additional API endpoint for steps, i.e. something like "get log segment for this step". That would be exactly what we need here. Maybe, you want to discuss that with GitHub for the benefit of your own IDEA plugin. If they would expose such an endpoint, you could get rid of lots of heuristic extra code and have a more easily maintainable piece of software. I would assume, that you like that prospect.

[kriegaex]

I got the update today. Thanks, the new heuristics improve the situation. But still, they are just that: heuristics. For example, take this job:

In IDEA, it looks like this:

This proves my point, that you should strive for an upstream API extension. FWIW, I already started talking to the GitHub folks, even though I still think, that is your job rather than mine. But I do believe in continuous improvement and in following up on problems.