Getting a broken pipe on initial publish command #3
Comments
|
Here's the stacktrace for the Broken Pipe, I can't gleam much useful data out of this. |
|
Interesting! What was the version in question? The second broken pipe is definitely expected; I wish there were a nicer way I could detect this and tell users "don't publish duplicate versions". The first one though is unexpected. Could it have been a transient network failure? Is this a multi-project build? |
|
Oh also, can you open a separate bug for the credentials issue? |
|
Here is a reproduction of the initial broken pipe error: https://github.com/halvorgb/spgreproduction to test: GITHUB_USER=user GITHUB_TOKEN=token sbt publisher/publish |
|
I'm not confident that the credentials issue isn't a user error from my side, supplying both from the environment (as above) works very well for me though. |
|
I encountered the same exact sequence of errors. The authentication error in the first step causes Github to write a The server time seems to be off causing an expiration of the request and the error. Subsequent calls then raise an exception because a After 5 or 6 attempts it suddenly works. |
|
@tverbeiren Are you user your local time is correctly sync'd? I've published (conservatively) thousands of times to Packages over the past month and haven't seen this error. Most of the time though, I've been publishing from GitHub Actions, though I've also done a fair amount of local publication. |
|
It's the first thing I checked, yes. It effectively looked as if the github side used the wrong timestamp so the cause may be on their side. BTW: Having to publish a couple of time in itself is not a big deal, but in combination with the lack of proper support - via the web interface - for deleting stuff from packages, versioning quickly becomes a pain. Do you have a suggested solution for removing a specific version from the packages list? |
|
@tverbeiren You can remove packages in the webinterface: |
|
@mkurz I guess I don't see the option in the web interface because it's a public repo then... |
This wouldn't surprise me. I've also noticed a lot of transient failures with GitHub Packages. It would be relatively generous to call it "in beta" at this point.
Yeah that part is a pain with public repos. It's fine with private ones, though there are still problems (e.g. artifact names become "sticky" to the first repository to which they are published, and even if you delete the published artifacts, you still can't move them to a different repo). I see why they don't allow deletion on public repos (and I do honestly support it), but it's a pain to be sure when you're trying to get stuff initially set up. I did a lot of work with snapshots. Also my company vomits out releases on our internal repos, so early experiments got buried quickly. There isn't a good solution for getting rid of the partially-broken stuff though. :-( |
Testing your plugin, it looks promising. Although I had to use explicit credentials to get it to work :)
The first time I run publisher/publish for my (private) project I get an exception (
[error] java.net.SocketException: Broken pipe (Write failed)). Although a package does get uploaded (I haven't yet tested if uploaded package works).If I repeat the command I get a
java.io.IOException: PUT operation to URL https://maven.pkg.github.com/<snip> failed with status code 422: Unprocessable Entity- which makes sense if it was already uploaded.The text was updated successfully, but these errors were encountered: