fix: pipeline diff fails on v10 #3154
Conversation
justinwilaby
force-pushed
the
jw/fix/pipelines-diff
branch
from
c281d71 to
eb79f9f
Compare
justinwilaby
had a problem deploying
to
AcceptanceTests
GitHub Actions
Failure
justinwilaby
had a problem deploying
to
AcceptanceTests
GitHub Actions
Failure
justinwilaby
force-pushed
the
jw/fix/pipelines-diff
branch
from
eb79f9f to
0281c0a
Compare
justinwilaby
had a problem deploying
to
AcceptanceTests
GitHub Actions
Failure
justinwilaby
had a problem deploying
to
AcceptanceTests
GitHub Actions
Failure
justinwilaby
force-pushed
the
jw/fix/pipelines-diff
branch
from
0281c0a to
451bc36
Compare
justinwilaby
had a problem deploying
to
AcceptanceTests
GitHub Actions
Failure
justinwilaby
had a problem deploying
to
AcceptanceTests
GitHub Actions
Failure
justinwilaby
force-pushed
the
jw/fix/pipelines-diff
branch
from
451bc36 to
b99b58e
Compare
justinwilaby
temporarily deployed
to
AcceptanceTests
GitHub Actions
Inactive
justinwilaby
temporarily deployed
to
AcceptanceTests
GitHub Actions
Inactive
justinwilaby
temporarily deployed
to
AcceptanceTests
GitHub Actions
Inactive
justinwilaby
temporarily deployed
to
AcceptanceTests
GitHub Actions
Inactive
justinwilaby
force-pushed
the
jw/fix/pipelines-diff
branch
from
5593f70 to
9821489
Compare
justinwilaby
temporarily deployed
to
AcceptanceTests
GitHub Actions
Inactive
justinwilaby
temporarily deployed
to
AcceptanceTests
GitHub Actions
Inactive
There was a problem hiding this comment.
I would suggest to split this PR into prioritizing a bugfix PR for the issue, and then a follow up PR with other refactors.
I agree in general that your implementation is correct. I would maintain things like introducing the Github interface types and remove those any types. But changes to the Fir types file are so huge that even Github won't display them. I would suggest for the bug fix to restrict the changes to the relevant interfaces (Pipeline, PipelineCoupling, etc.), if they're needed, avoiding other changes because of the potential risk of effecting other commands that rely on the current state of those interfaces.
If we want to update the fir.d.ts file by uploading another updated file autogenerated by the API schema converter tool, I would provide that as a separate PR with clear documentation on the interfaces that were updated and that are in use by any commands so we can test accordingly. I would love to rely on our current test suite to rule out any issues automatically, but we know there are commands that lack proper testing.
| } catch { | ||
| throw new Error(`unable to perform diff for ${targetApp.name} and ${downstreamApp.name}. Are you sure you have pushed your latest commits to GitHub?`) | ||
| } |
There was a problem hiding this comment.
I would avoid introducing new error messages and continue to rely on the error being surfaced by the API client with any messages returned by Github for now. This can be moved into a follow up refactor PR that will require review by CX.
There was a problem hiding this comment.
There would be no error other than a 404 by this response. Just a plain 404...no other info. Is that what we want?
| ux.error(`Unable to fetch pipeline ${coupling.pipeline!.name}`) | ||
| return | ||
| } |
There was a problem hiding this comment.
Same here as my previous comment. Just rely on the error returned by Platform API and don't introduce new error messages. This is different from the pipeline couplings get request in that we expect that request to fail under the scenario of the app not being part of a pipeline, but in this case, once the coupling was fetched this request isn't expected to fail, and the error returned from Platform API is more specific and probably more useful to the customer than a generic error message.
There was a problem hiding this comment.
Seems like there could be better consistency with the endpoints. How does a developer know when to use a custom error versus letting the error flow though from the API? When developing this fix, I put this error in intentionally because I didn't find the endpoint error particularly helpful. It was something like "Could not find the pipeline" or "pipeline not found" which wasn't helpful.
| @@ -29,7 +30,7 @@ export class BuildpackCommand { | |||
| async fetch(app: string, isFirApp = false): Promise<any[]> { | |||
| let buildpacks: any | |||
| if (isFirApp) { | |||
| const {body: releases} = await this.heroku.request<Release[]>(`/apps/${app}/releases`, { | |||
| const {body: releases} = await this.heroku.request<Heroku.Release[]>(`/apps/${app}/releases`, { | |||
There was a problem hiding this comment.
Why refactoring this back to the old schema types instead of the Fir ones?
There was a problem hiding this comment.
The fir schemas did not match the response from the server whereas the old schemas did.
Fixes the problem with pipelines failing on v10
use
./bin/run pipelines:diff -a heroku-vscode-stagingto test - this pipeline and apps should be accessible to all heroku-dev-tools team members