From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <ttaylorr@openai.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH] ci: pin actions in the main workflow to full commit IDs
Date: Fri, 23 Oct 2026 14:45:01 -0700 [thread overview]
Message-ID: <xmqqbj8k3xcy.fsf@gitster.g> (raw)
In-Reply-To: <a178dde02a80324d4cb52781d542ee575cbb68a1.1792773333.git.ttaylorr@openai.com> (Taylor Blau's message of "Fri, 23 Oct 2026 11:38:23 -0500")
Taylor Blau <ttaylorr@openai.com> writes:
> Some forks are hosted by organizations that restrict which GitHub
> Actions may run, including requiring actions to be pinned to full
> commit IDs. Our main CI workflow refers to actions by version tags or
> branches, which prevents it from running under such a policy.
I do not see why the limitations of other organizations should
affect our workflow here. What if another organization prefers
readable and concise tag names? Would they send a patch to revert
this change, leading to a "last one wins" situation?
Would it be too much trouble for organizations with this specific
requirement to maintain such changes in their own forks? When we
need to update a dependency (for example, when 'checkout@v6' is
deprecated and we transition to 'checkout@v7'), it would result in a
conflict anyway. At that point, someone has to translate the
symbolic name to a full object name. It seems only fair that the
organizations requiring this level of pinning handle that
translation themselves, and the conflict will tell them exactly
which line has the symbolic name that needs to be translated to a
full object name.
next prev parent reply other threads:[~2026-10-23 21:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 16:38 [PATCH] ci: pin actions in the main workflow to full commit IDs Taylor Blau
2026-10-23 18:05 ` Ben Knoble
2026-10-23 21:45 ` Junio C Hamano [this message]
2026-10-24 0:32 ` Taylor Blau
2026-10-24 1:38 ` Junio C Hamano
2026-10-26 18:08 ` [PATCH v2] " Taylor Blau
2026-10-26 18:20 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbj8k3xcy.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=ttaylorr@openai.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox