Skip to content
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

Inspect the installation script that publishes PowerShell modules to the Gallery #388

Closed
stijnmoreels opened this issue May 12, 2023 · 4 comments
Labels
management All issues related to management of the project
Milestone

Comments

@stijnmoreels
Copy link
Member

Describe the bug
The latest build (v1.0.1) failed with 'No such file or directory' while still successfully publishing the modules to the gallery.

To Reproduce
Steps to reproduce the behavior:
Not easy to test as it is a release pipeline.
Manual checks will be required.

Expected behavior
PowerShell modules are published and no errors are making the task fail.

Additional context
Add any other context about the problem here.

  • v1.0.1
@pim-simons
Copy link
Contributor

Confirmed that the logging was the issue, since after #407 the release to the powershell gallery succeeds without errors (see https://dev.azure.com/codit/Arcus/_build/results?buildId=80513&view=logs&s=10f6e304-9e13-543a-c8b5-64733a986fd7).

An earlier release failed where the nuget push returned a HTTP 400 bad request, which was correctly shown as an error and the release failed (see https://dev.azure.com/codit/Arcus/_build/results?buildId=80512&view=logs&j=d8644c48-ffa4-57a0-4dad-91968e195f84&t=c88a66d9-25c3-5b7a-40c9-937d8b63e849).
So I think we don't need to reintroduce the logging step, as a Bad Request is now shown as a failed pipeline run.
@stijnmoreels agree?

@stijnmoreels
Copy link
Member Author

The logging was mainly introduced (if I remember correctly) because we were having false positives for deployments. A failure (BadRequest) response was ignored and the step succeeded.
Maybe we could come up with another approach to do this extra verification?

@pim-simons
Copy link
Contributor

The logging was mainly introduced (if I remember correctly) because we were having false positives for deployments. A failure (BadRequest) response was ignored and the step succeeded. Maybe we could come up with another approach to do this extra verification?

From what I am seeing now the pipeline run fails with this error Response status code does not indicate success: 400 ... so that means the BadRequest errors should be handled right?
I don't think we need any extra logging then?

@stijnmoreels
Copy link
Member Author

Ok, that's great. Best of both worlds, then. Thx a lot for investigating and fixing this!
We can close this then, indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
management All issues related to management of the project
Projects
Status: Done
Development

No branches or pull requests

2 participants