| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* add MODULE.bazel
|
|
* v 0.9.0
* compat=1
|
|
|
|
* Add OutputGroupInfo for pkg_rpm rule
|
|
|
|
|
|
Fixes: #678
|
|
We could do more, but this should be good enough to start.
Fixes #644
|
|
|
|
Add primitive zip unicode filename handling tests
- Just make sure we can create an archive with non-ASCII file names.
|
|
* pkg_zip: improve support for long paths on Windows
This commit updates `pkg_zip` and `pkg_tar` to, when running on Windows, convert
files' input paths to extended-length paths by (1) making them absolute
and then (2) prepending with `\\?\`.
|
|
- Update to a newer rules_license
- update ci to prove that we can work with --incompatible_use_platforms_repo_for_constraints
- do not test with no_host_transition yet
|
|
Genericize package manifest system and interface
The current way that rules_pkg communicates with must packagers is using a
manifest file, which is currently a JSON data structure based on a an array of
arrays. While generally readable, it looks strange, as it was to reduce Bazel
resource usage (JSON strings in memory). Further, our Python code is directly
bound to this data structure format.
However, if we want to add more or change this, it becomes cumbersome on both
the Starlark and Python sides. This change alleviates concerns generally by:
- Converting all manifests to a JSON "object" style, improving readability.
Numerous golden tests were updated to support this.
- Replace the `collections.namedtuple`-based `ManifestEntry` object with one
that is a little more flexible and type-safe.
- Providing a function (`read_entries_from`) that converts a file-like object
into a list of `ManifestEntry`s, and replacing all JSON reading in packagers
(`tar`, `zip`, `install`) and their tests with this function.
Other convenience factors or things addressed:
- `ManifestEntry.entry_type` is now just `ManifestEntry.type`
- Bazel 6 now stringifies repository-local labels with a preceding `@`, unlike
prior versions. Adapt to this in the manifest writer.
Future changes will extend this interface to allow for custom attributes to be
passed from `pkg_files` and friends, which, among other things, will be
necessary to more generically support `pkg_rpm`.
Provides groundwork for (but doesn't resolve) #385.
|
|
|
|
Fix version number
|
|
* feat: expose tar manifest as an output
This allows targets to run something like jq over the manifest contents
|
|
Add optional attribute to add a short license description to the meta data of created debian artifacts
|
|
Fixes #648
|
|
|
|
* Explicitly store implicit parent directories in zip files
Tooling in the Java world (and likely elsewhere) has come to depend on
all directories implicilty present as parent directories of files to be
listed explicitly as a member of a ZIP file.
* Address review comments
|
|
Avoids flattening depsets during the analysis phase by passing depsets
into `ctx.actions.run`'s `input` parameter.
|
|
- Fix brokenness in pkg_tar
- Add tests (it was working) to pkg_zip
Fixes #610
|
|
|
|
|
|
Tidying
|
|
|
|
|
|
Stop pointing at specific releases.
|
|
* update version and changelog for release
* fix a brittle test that depended on rules python internals. It fails depending on which Bazel you use, even though the rule is doing the right thing.
Force merge so I can get the release to unblock last minute bazelcon demos.
|
|
Add example of new ctx.var and $(var) usage in file names.
Update common docs
- fix since regexp
- use 0.8.0 for since
- remove unneeded load
|
|
* Make sh tests portable
|
|
* Create basic bzlmod setup for rules_pkg.
- Shows it working for one example
- Has only runtime deps
- rpm and git toolchains not done yet
- Still not sure how to get the external repo test working
- Make platforms and stardoc dependency deps.
|
|
|
|
* Fix config_setting visibility failure on bazel CI
See https://github.com/bazelbuild/bazel/issues/12933.
Repro: `$ USE_BAZEL_VERSION=a05276fea75d47370b363125a074c38cb2badc74 bazelisk build --nobuild --incompatible_config_setting_private_default_visibility //src/main/java/...`
Discovered in failing Bazel CI with `--incompatible_config_setting_private_default_visibility` flipped
|
|
When we merge generated docs into the final form, convert
@since(text) to emphasized (currently italic) text.
This is not intended to be perfect. It is just to get the concept out
there to start playing with it. Ideally, StarDoc will eventually support
@since natively and we can delete this.
|
|
* Allow $(var) substitution in filenames and include everything in ctx.var in the substitution dictionary.
Fixes #20
|
|
* Adjust tar test to show #297
I tried to revert many pieces of code which should have fixed the problem, but could not reproduce 297. I'm fairly confident the root cause was eliminated a while ago.
|
|
* Cosmetic. Improve the error messageing on duplicate files in check_dest.
* lintify
|
|
* First cut at runfiles in pkg_* rules
* allow long paths in write_manifest to aid debugging
|
|
|
|
* Create an example of the kind of link tree Node users muse create
|
|
|
|
No new feature, I just want the test to make sure we don't backslide on this.
|
|
* fix #612
* check that directories get the right mode
|
|
|
|
* Properly format the deb Description field, fix format of changes file.
A combination of fixes and then tests for the behavior:
- Stop text wrapping the description. The "displayer" should do the wrapping.
- Create the changes "Description" field in the correct format.
- Do not allow newline in single line fields.
- Add leading space to continuation lines in multiline fields.
https://www.debian.org/doc/debian-policy/ch-controlfields.html
Fixes: #522
* do not test description on windows
|
|
This means that:
1. you'll get the same format no matter what version of Python you have.
At Python 3.8 the default changed from GNU to PAX.
2. The default will be suitable for building Debian packages containing
long file names.
A followup PR may add the capability to allow PAX tar writing, but I
do not know the urgency of that at this time, so that is a future
feature request.
Fixes #216
|
|
Indicates that WORKSPACE setup can be found in the release notes.
|
|
|
