-
Notifications
You must be signed in to change notification settings - Fork 261
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
Release pipeline unreliability - improvements needed #3194
Comments
Updated https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-19687 with link to issues here |
When running the 2.0 pipeline, surprisingly the release pipeline finished without error However on inspection the sync failed - for example
It's not clear how the staging repo issue happens -- here we had the first run of the job, and since that is all handled by jfrog it looks to be an issue their end. The maintenance is common with maven central - we need to detect, or at least verify at the end of the job & iterate. (kicked off job again manually for this release, but process needs improving) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions. |
These problems persist, and make the release process take longer than idea (a single click/approval) In addition we have recently switched our PR process over to github actions, and started investigating gradle builds. So other areas to consider include
|
Opened up a request with the Linux Foundation to see what support they may be able to provide generally, and also specifically in terms of the bintray/JCenter/maven central sync -- which is the current biggest pain point https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-20990 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions. |
This is now superceeded by #4664 as we need to rewrite the pipeline completely (most likely). |
Over a number of releases we have hit problems with the current release pipelines which need further investigation
In #3132 we observed two artifacts (including 'org.odpi.egeria:rex-view' were not present at the 1.8 level in bintray, jcenter - and therefore not synced to maven central. They were present in other artifactory repos include egeria-release-local
No errors were shown in the logs that I could see - need to understand how this happened, and whether we need some explicit artifact by artifact checks to ensure artifactory->bintray has gone correctly, beyond trusting the jfrog cli
There seems no way to programatically add an artifact to JCenter. It would be useful if we could either automate this or invoke some kind of stewardship task to get a person to add.
On occasion this may fail due to pom structural issues -- and in these cases we need to be able to build that artifact from the release git branch again and push through the process.
(originally raised in #2917 ( IT-19687 )- feel free to reopen, but tracking here only for now)
(Current workaround is a local/manual build and upload)
The syncing to maven central can take many hours. A pipeline job can only last 6 hours before it times out and is killed. The last release ended up taking 4-5 iterations purely due to time, and another 3 or so to address anomolies.
We need to automatically restart the job in some way - perhaps through an additinoal job that monitors the release. It should be able to resume from the right place. I can't see maven central performance changing any time soon, we still want to publish there.
(originally raised in #2704 ( IT-19687 )- feel free to reopen, but tracking here only for now)
The JC->maven central job can also fail to sync artifacts due to outages at maven central. As above we need to be able to recover from this
Currently we seen to sync artifact by artifact from artifactory->bintray->JCenter->maven central. Whilst the earlier 2 steps are fairly quick, the last in particular takes a long time (as above). This means a new egeria release drips out over many days. This can cause users issues as they see a new release (or use 'latest') and it is incomplete.
Need to figure out how to make this transactional ie all or nothing.
Since the pipelines are only run monthly, we often don't see issues until too late.
We need to consider how to make it easier to run this pipelines more easily as a test - perhaps publishing to a different version tag or package name... but keeping as close to the normal process as possible.. Maybe utilizing snapshots. The objective is to spot issues sooner.
The text was updated successfully, but these errors were encountered: