Package build trigger mechanism (esp. if fission packages are deployed with gitops)

[mersl]

Rethink the way, builds are triggered
Using fluxci/gitops, I successfully managed to create all routes, functions and packages using the given CRDs incl. pipelines etc. But at one specific stage, the process breaks by fission design since the rebuild of changed packages is not triggered.

Example object:

apiVersion: fission.io/v1
kind: Package
metadata:
  creationTimestamp: null
  name: demo-package
spec:
  deployment:
    checksum: {}
  environment:
    name: python
  source:
    checksum: {}
    literal: %%SOME BASE64 encoded zipfile containing source code%%
    type: literal
status:
  buildstatus: pending

on initial deploy with flux (remember, SSA is enforced), the resource is created and the build process starts since .status.buildstatus is in state 'pending'

Whenever a package update happens, flux updates the resource in the end. In my example this is mainly .spec.source.literal. But fission will not trigger a rebuild of the package since the buildstatus was successful. Even if one would overrule ssa and update buildstatus to pending again, it would result in a rebuild of the package every flux reconcilation interval - for example all 5mins, which is not desireable as the code might not have changed at all.

Potential solution
Trigger rebuild of packages, if the resource spec changes. For example an increase of .metadata.resourceVersion would be another potential candidate as identifier for a changed resource.

Current workaround
Since the pipeline uses kustomize in the background, I deploy in two stages:

1. run kustomization without the package referenced and having resource purging enabled; this causes the package resource being deleted
2. re-run after some wait time (aligned with recon-interval of flux) kustomization with the package included, which newly creates the resource and build is triggered

If there is no change in code, flux is not changing the package resource and no un-needed rebuilds are actioned.

Drawback: if there is a redeployment, a service interruption happens since the package is not available for a period of time. This is acceptable for the current function, but might not for others.

Alternatives considered
I changed the flow to reference .spec.deployment.url instead and prepared a ready-to-use package by myself in my CIs. (actually using the fission builder env container, extract the built data, zip and upload to some website). This does work of course, but ignores the fission built-in beauty of package building.