[release] org.jreleaser.sdk.commons.RestAPIException when releasing to gitlab.com #755
Comments
aalmiray
changed the title
|
After trying to figure out what happened, I noticed that I checked the trace.log from the root project that dated from another attempt... I updated the trace.log and it gave me the reason : 413 Request Entity Too Large My apps zip and tar.gz are around 50M and it appears that the attachement limit on gitlab.com is 10M. AFAIK there is no way to change this limit on a repository basis... Will have to try another upload infra... |
|
You can try using the uploadLinks feature. This requires uploading assets to an external location such as AWS S3 or a JFrog Artifactory instance. https://jreleaser.org/guide/latest/configuration/release/gitlab.html Here's how the taxi-lang project does it as they faced the same problem https://gitlab.com/taxi-lang/taxi-lang/-/blob/develop/taxi-cli/jreleaser.yml |
|
Well, I do not have access to s3 or artifactory instance, but could upload using ssh. Are there plans to allow wagon-ssh like uploads ? |
|
Possibly. We also support custom HTTP/HTTPS of your choice as long as the service supports POST or PUT. Upload via ssh would have to wait after |
|
@serasset just to have a clearer understanding for shaping the scp/sftp upload feature for later: the idea is to use scp/sftp to upload assets to a given server, said assets will be publicly available for download through other means such an https? The reason for asking is that currently uploaders expose both upload and download urls. In the case of of scp/sftp JReleaser would still need a download url of some form, hopefully without requiring access credentials. |
|
Well, in fact, until then I had a scpexe:// url for my distributionManagement>repository in maven and maven deploy was simply deploying there (using wagon-ssh extension) and the artifacts where available at a public URL. In maven, the upload URL was specified in delivery management and the download url in the repository section. They are only linked as they have the same id, but it is not necessary for maven. As I tried to use JReleaser I wanted to use gitlab for releases as I switch to it for my repository (I was previously on bitbucket which does not offer such a releasing capacity). But the upload limit on gitlab prevent me to do this. I have no access to a S3 or artifactory instance and do not really want to setup my apache for uploading through http(s). So I thought about :
While trying to setup this configuration, It was quite tedious to configure the scpexe credentials on CICD image, so I gave up and finally, I mirrored my repo on github and I release on github. Now I'm not really sure scp is a good choice as managing the credentials in a CICD workflow is tedious and may be a too high security risk (you really need to configure a ssh key allowing only scp access and it is not an easy click and copy process). Maybe git pages would be better fitted for this as it looks like what is done for homebrew rule creation for instance. |
|
Thanks. I did see the github mirror of your project (congrats on the release btw). Been working on download/upload capabilities using http/scp/sftp and happy to share it's almost there. The last stumbling block is setting up the SSH keys ate the right location which could be done like it is for PGP keys in the |
|
2 people from GitLab have suggested using the generic packagers option. This requires a bit of work and constitutes a big change for the current state of the project (so close to Generic packages currently require a version number that follows semver. JReleaser supports 5 different versioning schemes which may or may not be compatible with semver depending on the chosen format. We already have two options in place (jpackage.applicationPackage.appVersion and chocolatey.packageVersion) that check if the chosen version number is valid (which happens to be something very close to semver). The bigger change is making use of the REST API to upload binaries to a Generic package. I know it's not exactly what you wanted to hear but the fact that there are "workarounds" (use any of the 3 uploaders currently supported || use GitHub or Gitea) does not block the next big release. |
|
Closing in favor of #822 Alternative is to upload binaries to another location (JFrog Artifactory, AWS S3) or host binaries on GitHub/Codeberg |
Task List
Context
I am in the process of trying to use JReleaser for a multi-module maven project dbnary. The configuration of the project is the following
The jreleaser configuration is defined in a profile in the root project and bound to deploy phase:
the dbnary-commands module activates jreleaser in the same profile id:
Notes all these commands are launched locally (not in gitlab CICD):
JRELEASER_GITLAB_TOKEN=.... mvn -e -Djreleaser.dry.run=true -Pjreleaser deployruns fineJRELEASER_GITLAB_TOKEN=.... mvn -e -Pjreleaser deploybreaksThe specified token is a gitlab personal access token bound to my account (repo owner) with all scopes checked.
Expected Behaviour
I'm expecting the mvn deploy to send the assemblies as a gitlab release
Actual Behaviour
The command breaks with an error, while on the gitlab instance, the tag is created and the release attached to it contains the changelog + 4 source assets (zip, bz2, tar.gz and tar), but no other files.
Stack trace is :
Environment Information
The text was updated successfully, but these errors were encountered: