If this is the only zip bundle that will need entitlements, then my suggestion would be to not make a special purpose template for it. Just write the files in this target and include them in the file list parameter to zip_bundle. If the same pattern is needed for multiple zip bundles, and all the targets for them are in this BUILD.gn file, then define the helper template directly in this file.

Yeah the same pattern is needed for multiple zip bundles, which live in different BUILD.gn files, such as andriod, mac, tools etc. I put the logic in a template to save some typings.

Yeah I only included artifacts.zip in this commit. This is based on the feedback to start with a single zip, and smaller pr for easy review. (#34112 (review))

I see. I think it could still be a bit cleaner to factor this a little differently instead of using a special purpose zip_... template. One idea that I'm not 100% about would be to make a template specifically for the metadata files. That template would accept the same file list-of-scopes that is passed to the zip_bundle template. You can set additional values in those scopes that indicate whether the files are "with" or "without" entitlements:

files += [
  {
    source = "//third_party/icu/flutter/icudtl.dat"
    destination = "icudtl.dat"
    entitlement = "none" # neither "with" nor "without"
  },
  {
    source = "$root_out_dir/flutter_tester$exe"
    destination = "flutter_tester$exe"
    entitlement = "with" # or "without"
  },
  ...

With a template like:

template("write_entitlements") {
  with = []
  without = []
  foreach(file, invoker.files) {
    if (file.entitlement == "with") {
      with += [...]
    } else if (file.entitlement == "without") {
      without += [...]
    }
  }
  write_file(..., with)
  write_file(..., without)
  # Might need a copy() target here to make this a real template from which you can capture the outputs.
}

Then in the zip_bundle rule, you can depend on the write_entitlements target, and extract its outputs with get_target_output.

actually let me rewrite my response.

Instead of saying entitlement = "none", it might work to say e.g. defined(file.entitlement) && file.entitlement in the write_entitlements template.

Discussed with zra offline and the current plan is to collect metadata through the generated_file api.

I am currently looking at how to make generated_file target work with the zip_bundle template. Because they can't be nested, and system would complain You are trying to nest a target inside a template invocation.

nit: This could use zip_bundle to avoid duplicating code.

Sure, will do.

Yeah I thought about reusing zip_bundle previously, and realized the cons is, I would have write_file functions appended to every BUILD.gn file, instead of only defined once in the template. But the pros of reusing zip_bundle is, I don't have to define a new template function.

Why is this list of files included?

Yes this is the list of file paths, in the produced engine artifacts, that should be codesigned with entitlements.

In this example, the produced artifact is artifacts.zip. And flutter_tester is one of the file paths inside artifacts.zip that should be code signed with entitlements. By including flutter_tester this list, we encode the information that artifacts.zip/flutter_tester should be code signed with entitlements.

I'm more interested in how we chose this set of files. Is it only the files that have an executable bit set? if so, we can automate searching the generated directory for the executable files instead of hard coding them.

yes all the engine binaries, when detected, fall into one of the 3 categories:

1. in a hard coded list of entitlements, so that it should be code signed with entitlements.
2. in a hard coded list of without_entitlements, so that it should be code signed without entitlements.
3. not in any hard coded list, this is likely caused by new addition/deletion of engine binaries. This will throw an exception, and require user to update information on the new binaries.

If we just search for binaries, we can't tell whether it should be code signed with or without entitlements, and whether there is change to the existing artifacts. The full logic for this part is hosted in go/code-signing-standalone.

I'm more interested in how we chose this set of files. Is it only the files that have an executable bit set? if so, we can automate searching the generated directory for the executable files instead of hard coding them.

macOS binaries that run on the host with gatekeeper need entitlements. iOS target binaries must not have entitlements, because when we build the iOS app, Xcode will sign them, and I believe if a binary already has entitlements and it gets resigned with different entitlements bad things happen?

Are there any other modes? If not, we can simplify and remove the else block.

file_with_entitlements = [ "gen_snapshot" ]
if (flutter_runtime_mode == "debug") {
  file_with_entitlements += [...]
}

Yeah I thought about this, and wasn't sure if there are other modes. If not, we can remove this.

nit: We should generalize the wording here as other platforms support entitlements