jenkins-library
jenkins-library copied to clipboard
SAP
Piper library is temporarily unavailable after merge to the main branch
After merging a change to the main branch the latest revision in git is updated immediately, however it takes a while to upload the new piper artifact to the repository. In this time pipelines that point at the main branch of this repository fail to fetch the piper library. This introduces some instability to such pipelines. As far as I understand pointing at the main branch of Jenkins libraries in general is considered a best practice.
Thank you for your contribution! This issue is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I am not able to remove the stale label as I do not have permission to do so. @SAP/jenkins-library-team could you please have a look at this issue?
Thank you for your contribution! This issue is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.
I am not able to remove the stale label as I do not have permission to do so. @SAP/jenkins-library-core could you please have a look at this issue?
After merging a change to the main branch the latest revision in git is updated immediately, however it takes a while to upload the new piper artifact to the repository. In this time pipelines that point at the main branch of this repository fail to fetch the piper library. This introduces some instability to such pipelines. As far as I understand pointing at the main branch of Jenkins libraries in general is considered a best practice.
Hi Alex, I don't believe it is best practice to point at the master branch of Project Piper. We have a new release once a week, please use a released version. Did that answer your question?
I don't believe it is best practice to point at the master branch of Project Piper. We have a new release once a week, please use a released version.
Sure? I still hear @OliverNocon saying it is the recommended approach... ?
From my perspective setting a fixed version would resolve the issue, I also think this is a good idea to reduce the number of moving parts in the build, however to my best knowledge this is the best practice.
Maybe there could be a tag "latestRelease" that is updated by the weekly release build to point to the newly created release?
e.g. something like this... git tag -d latestRelease git push origin :refs/tags/latestRelease git tag latestRelease git push origin latestRelease
Maybe there could be a tag "latestRelease" that is updated by the weekly release build to point to the newly created release?
e.g. something like this... git tag -d latestRelease git push origin :refs/tags/latestRelease git tag latestRelease git push origin latestRelease
I like the idea to point to a slightly more stable version, while keeping things reasonably up-to-date without effort.
Maybe there could be a tag "latestRelease"
Since it moves frequently it looks more like a branch than a tag. Tags are supposed to be stable, even if it is possible to reset tags.
Regarding the master vs tag discussion: It's a tradeoff between being up to date vs having a stable build. The more important a stable build with less moving dependencies is the more likely is it so choose a tagged version.
Thank you for your contribution! This issue is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.
Please remove the stale label, the discussion is not resolved, the issue still exists.
Thank you for your contribution! This issue is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.
Please remove the stale label, the discussion is not resolved, the issue still exists.
@lextiz could you please detail the problem you have?
We see in our telemetry a very high number of pipeline runs not having this problem you describe.
@OliverNocon The problem is described in detail in the original issue description: at the time when Piper release pipeline is running the Piper artifact is partly not available. Is something missing there? As of the telemetry, I do not think this is applicable to this issue, as piper library is not getting downloaded at all, so the telemetry code is not being executed.
there can be a very small time gap where a new release is created and no binary is attached to the release. This is known and appropriately handled:
For this case there are various fall-back/resilience options implemented, e.g.: https://github.com/SAP/jenkins-library/blob/master/src/com/sap/piper/PiperGoUtils.groovy#L58
Could you please provide a concrete error log where this still caused a problem?
@OliverNocon Attaching the log is a good idea, however the logs were rotated out long time ago, if I am not mistaken you would see the same printout (Download of Piper go binary failed.) repeated 12 times. As far as I remember the issue happened to me at least 2 times and in both cases the "downtime" was significantly longer than 2 minutes that are defined as timeout in the robustness mechanism, it was at least 2 hours.
To be honest, if it was 2 hours it was not related to the release process per se but likely happened due to some other bug maybe even some general network issue.
Maybe you can provide detailed information once it occurs the next time on your side. We do have monitoring and telemetry in place in order to safeguard productive pipelines. I am not aware of a recent problem of such kind.