From: "Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luangruo@yahoo.com, 74413@debbugs.gnu.org, stefankangas@gmail.com
Subject: bug#74413: [PATCH] Allow to store and read repository information of VCS builds
Date: Tue, 19 Nov 2024 18:13:14 +0200 [thread overview]
Message-ID: <87ttc3td5x.fsf@thaodan.de> (raw)
In-Reply-To: <86wmgztfse.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Nov 2024 17:16:33 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: stefankangas@gmail.com, luangruo@yahoo.com, 74413@debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 23:48:38 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I still don't think I understand, sorry. Do you mean the file is
>> > generated from a Git repository, but then Emacs is somehow built from
>> > a directory that is not under Git?
>>
>> The file can be generated from the git repository outside of the Emacs
>> builder.
>
> So you mean someone will chdir to the Git repository, say
>
> $ make etc-emacsver
>
> Then take the produced file and manually install it when Emacs is
> built (in another directory) and installed, is that right?
I extract the file from the obs service and generate file from the
services metadata. The make target is there to create the file if Emacs
is built with git installed or if the target is used in the way you
mentioned above.
In both cases the emacs VCS functions will still work after the built
without the sources or git installed, in the case of the former
as long as in the packager has provided the metadata themselves.
>> > But if this is the scenario, how can you be sure the produced Emacs binary was made from that revision
>> > on that branch? This is only guaranteed if you actually build from
>> > Git when you record this information.
>> >
>> > What am I missing?
>>
>> If the source is generated by the CI it can also store this information
>> in the build source which then can be extracted from the ci metadata to
>> the Emacs sources on the builder.
>>
>> I can be sure that Emacs was built from that revision as much as I can
>> trust the CI to use the sources I told it to use. If I can't trust one,
>> I can't trust the other.
>
> But CI builds from Git, doesn't it? If so, the Emacs it produces
> already records the revision and the branch.
The source generator, the source service runs git but the builder
doesn't.
Because the builder doesn't have to deal with git the rebuild chain is
smaller, build dependency changes can trigger rebuilds, and the worker
doesn't have to have git installed.
In most cases it's not required or wanted that worker have git as the
only allowed purpose would be to get access already existing metadata but
not change anything on the sources itself.
Providing the metadata to the VCS emacs-repository-branch and
emacs-repository-version with the previously generated metadata that
belongs to the package sources removes the need for git in the build worker.
next prev parent reply other threads:[~2024-11-19 16:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wmh1j6po.fsf@>
2024-11-18 12:45 ` bug#74413: [PATCH] Allow to store and read repository information of VCS builds Eli Zaretskii
2024-11-18 14:21 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875xoklj13.fsf@>
2024-11-18 14:55 ` Eli Zaretskii
2024-11-18 16:54 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87frnowkhp.fsf@>
2024-11-18 19:03 ` Eli Zaretskii
2024-11-18 19:31 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <874j44wd7k.fsf@>
2024-11-18 19:41 ` Eli Zaretskii
2024-11-18 21:48 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87y11g5i2x.fsf@>
2024-11-19 15:16 ` Eli Zaretskii
2024-11-19 16:13 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-11-19 17:08 ` Eli Zaretskii
2024-11-20 7:55 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 23:48 ` Stefan Kangas
2024-11-19 6:35 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 15:19 ` Eli Zaretskii
2024-11-19 16:16 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 17:20 ` Eli Zaretskii
2024-11-18 8:18 Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttc3td5x.fsf@thaodan.de \
--to=bug-gnu-emacs@gnu.org \
--cc=74413@debbugs.gnu.org \
--cc=bjorn.bidar@thaodan.de \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
--cc=stefankangas@gmail.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).