Tractus-X
EDC (and upstream EDC, fwiw) has been
using dependabot for quite some time now
and with good success, and we have yet to
encounter any real issues.
Usually,
breaking changes of libs only happen on
major version bumps, in which case some
manual work is required. If there are
breaking changes, we typically fix them
either in a separate PR (as Felipe
suggested), or - if the changeset is
limited - directly on the dependabot PR.
The latter can only be done by
committers. I would personally avoid
libraries that don't do minor/patch
upgrades.
There
is one small pitfall though: as you know,
EF requires the presence of a
DEPENDENCIES file, and Tx-EDC has
opted to always keep that up-to-date and
fail the build if it is out-of-date. The
worklfow action for this can be checked
our
here.
Naturally,
every dependabot PR will cause that file
to get out-of-date (and thus fails the
build), so we approach this in on of two
ways:
-
if there is just one dependabot PR, we
manually update the
DEPENDENCIES file directly
on the PR
-
if there are several dependabot PRs, we
merge all but one, and manually update the
file on the last one
While
it would be trivial to automatically
regenerate the DEPENDENCIES file during
the build, we opted against it for three
reasons:
-
That would cause potentially a ton of
spurious commits by a bot, confusing the
reflog even more
-
Developer awareness: updating a dependency
should be a conscious effort and not done
inadvertently
-
IP lab requests: whenever we update a
dependency, we potentially need to file
an IP lab request, which we do constantly
over time, as opposed to once before a
release.
Lastly,
I would like to remark that having
"non-updateable dependencies" in a project
is a serious smell. Every project should
always keep their deps up to date to avoid
security vulnerabilities etc. Not doing so
only builds technical debt and fosters
developer laziness and will cause pain
down the road.
sorry
for the wall of text, thanks for reading.
Hello
everyone,
Please
apologize the reaction being sent as a
reply-all to the list.
Together
with that positive feedback, I want to thank
you Tomasz for the Dependabot TRG and ask if
there is any plan on how to move forward
with some specific dependency update in case
it breaks the build.
In
the past, on a small team, I had a good
experience closing those Dependabot PRs and
opening a ticket to investigate and fix that
specific update.
Also,
it can be helpful to have documented for
each project the list of “non-updatable
dependencies”, as they might incur breaking
changes, re-work, or any other consequence
that blocks a library to be updated to a
specific version.
Any
thoughts about that?
Thank
you.
Felipe
Zampa Fonseca
Application Architect Core Services
Cofinity-X GmbH │c/o Im Mediapark 5 │50670
Köln
E : felipe.zampa@xxxxxxxxxxxxxx
M : +49 176 15344601
Booking
|
LinkedIn
![Signature-Logo.png]()
Mandatory
Disclosure Statement:
www.cofinity-x.com/impressum
This
e-mail may contain trade secrets or
privileged, undisclosed, or otherwise
confidential information. If you have
received this e-mail in error, you
are hereby notified, that any review,
copying, or distribution of it is strictly
prohibited. Please inform us immediately and
destroy the original transmittal. Thank you
for your cooperation.
Dear
Tractus-X Community,
I hope this email finds you well. I’m
excited to share an update regarding new
GitHub Dependabot Tractus-X Release
Guideline.
The aim of the TRG is to help us
automatically track and manage
dependencies, ensuring that our
projects remain secure and up to date.
The
document is currently available in draft
form and is ready for your review.
You can access the document
here.
Encourage you to review the document at
your earliest convenience. Feel free to
share any comments, suggestions, or
questions you may have directly on the
document or by replying to this email.
Thank you for your continued support and
collaboration.
Best regards,
Tomasz
Barwicki
