Add guide for tracking Source files in dist-git#1142
Conversation
majamassarini
force-pushed
the
track-source-in-vcs-2365
branch
from
3de765e to
d35c089
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 09s |
nforro
left a comment
nforro
left a comment
There was a problem hiding this comment.
A little too verbose for my taste, but definitely better than nothing 🙂
| ### Multiple files | ||
|
|
||
| For more than one file, list them in `files_to_sync` and stage them in a single | ||
| command. Using `git add -- <paths>` keeps the action robust against future | ||
| files that match dot-prefixes or unusual names: | ||
|
|
||
| ```yaml | ||
| files_to_sync: | ||
| - pkg.spec | ||
| - pkg.service | ||
| - pkg.socket | ||
| - pkg.sysusers | ||
|
|
||
| actions: | ||
| post-modifications: | ||
| - bash -c 'cd "${PACKIT_DOWNSTREAM_REPO}" && git add -- pkg.service pkg.socket pkg.sysusers' | ||
| ``` |
There was a problem hiding this comment.
Is this meant to discourage using git add * or git add .? If yes, I would state that explicitly, becuase otherwise this whole paragraph seems redundant - everything is practically the same as for a single file.
There was a problem hiding this comment.
The reason why the agent added this example and it isn't using git add * is explained.
Using
git add -- <paths>keeps the action robust against future
files that match dot-prefixes or unusual names:
$ git add * # so this misses .env
$ git status -s .env
?? .env # still untracked
$ git add -pkg.service
unknown switch `p'
usage: git add [<options>] [--] <pathspec>...
$ git add -- -pkg.service # works
These are really corner cases, so if you want I can remove this paragraph, but I think this is a useful tip.
There was a problem hiding this comment.
I think this is a useful tip.
Exactly, so I would convert it to a tip admonition and shorten it to one ot two sentences (do not use git add . or git add *, use git add -- file1 file2 instead).
|
|
||
| ### `post-modifications` | ||
|
|
||
| This action runs in the release-synchronization workflow after the spec file |
There was a problem hiding this comment.
Not true (or badly formulated), it runs in upstream jobs as well.
There was a problem hiding this comment.
I don't read it as it runs only in release-synchronization. I read it as it runs after the specfile has been modified during the release-synchronization. 🤔 or I don't follow you.
There was a problem hiding this comment.
That's why I said badly formulated. You can read it both ways, let's use different wording.
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 07s |
Add a how-to that shows how to use the post-modifications action (or pre-sync for URL-based sources) together with files_to_sync to keep small extra Source files in dist-git's VCS rather than uploading them to the lookaside cache on the first sync. Assisted-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Nikola Forró <nforro@redhat.com>
majamassarini
force-pushed
the
track-source-in-vcs-2365
branch
from
9aecd40 to
eb87d98
Compare
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 12s |
3 participants
Add a how-to that shows how to use the post-modifications action (or pre-sync for URL-based sources) together with files_to_sync to keep small extra Source files in dist-git's VCS rather than uploading them to the lookaside cache on the first sync.
Link to the new guide from the existing note in the configuration index and from the actions reference.
Fixes packit/packit#2365
Assisted-By: Claude Opus 4.7 (1M context) noreply@anthropic.com