Release workflow for meta-qcom

[abinjose-qualcomm]

From: #1944

@rsalveti: We didn't have the lock file before, and we think we can keep maintaining the lock file for the wrynose branch as part of meta-qcom, then we could indeed just tag and be done.

There are a couple of downstream automations that depend on the existing release workflow based on meta-qcom-releases repo. Before making the switch, I wanted to clarify expectations and address potential edge cases.

• meta-qcom-distro is currently excluded from the lock file, but will need to be locked as part of the release commit. If a nightly build is being considered as a release candidate, development would need to be frozen until the meta-qcom-distro SHA is pinned.
• glymur is expected to be released from mainline, which means a lock file for the release will also be required in the master branch.

[lumag]

From: #1944

@rsalveti: We didn't have the lock file before, and we think we can keep maintaining the lock file for the wrynose branch as part of meta-qcom, then we could indeed just tag and be done.

There are a couple of downstream automations that depend on the existing release workflow based on meta-qcom-releases repo. Before making the switch, I wanted to clarify expectations and address potential edge cases.

I have been asking for the reasons of having a separate releases repo and got nothing. Could you please clarify, what is dependent on that repo and what is the possible impact (from the engineering and from the end result PoV). As this concerns downstream, feel free to have that discussion either here or on in the internal media.

• meta-qcom-distro is currently excluded from the lock file, but will need to be locked as part of the release commit. If a nightly build is being considered as a release candidate, development would need to be frozen until the meta-qcom-distro SHA is pinned.

Yes, it is expected that meta-qcom-distro will be pinned via the commit ID in the lock file (see

• glymur is expected to be released from mainline, which means a lock file for the release will also be required in the master branch.

I think it's a separate topic. However up to now Glymur should also have been properly integrated into the corresponding branch. Is there a reason for releasing support for that platform as a separate target? Are we talking about using qcom-6.18 vs qcom-next kernels for different targets?

[abinjose-qualcomm]

I have been asking for the reasons of having a separate releases repo and got nothing.

Based on initial discussions with @rsalveti / @ndechesne in January, the recommendation was to maintain a separate repository for release artifacts because they didn't want to maintain a lock file in meta-qcom at that point in time.

Could you please clarify, what is dependent on that repo and what is the possible impact (from the engineering and from the end result PoV).

• qsc-cli provides a wrapper for performing end to end builds (including firmware compilation) in a containerized environment and internally invokes the meta-qcom release build steps.
• The downloads mirror on CodeLinaro is populated based on the release build for meta-qcom and relies on the release workflow steps.

There would be no functional difference between building the release from meta-qcom or meta-qcom-releases. The teams involved would need to informed and would take some time to validate the new workflow.

From a DX perspective, tagging meta-qcom directly would be a better approach as it simplifies the build steps. However, this would be a developer touch point since we are changing the way releases are built.

[lumag]

We have enough legacy steps already in 2.0 (like having the CI in the meta-qcom rather than meta-qcom-distro). I don't mind having a separate repo for 2.0 releases, provided it is committed after we commit and tag the release here in meta-qcom. Meanwhile we can migrate all our internal users towards consuming the tags from the new location.

[ricardosalveti]

• glymur is expected to be released from mainline, which means a lock file for the release will also be required in the master branch.

This is somehow new to me, we never discussed releasing master, but since we do have a lock file in master now, we could create a tag for a master-based milestone. The only thing we won't necessarily have with master is a RC/release freeze, as that directly affects the integration of this layer with oe-core/yocto.

[lumag]

• glymur is expected to be released from mainline, which means a lock file for the release will also be required in the master branch.

This is somehow new to me, we never discussed releasing master, but since we do have a lock file in master now, we could create a tag for a master-based milestone. The only thing we won't necessarily have with master is a RC/release freeze, as that directly affects the integration of this layer with oe-core/yocto.

I'd rather understand, where that comes from and maybe keep qcom-next kernel in the wrynose branch.

[abinjose-qualcomm]

We have enough legacy steps already in 2.0 (like having the CI in the meta-qcom rather than meta-qcom-distro). I don't mind having a separate repo for 2.0 releases, provided it is committed after we commit and tag the release here in meta-qcom. Meanwhile we can migrate all our internal users towards consuming the tags from the new location.

Sure, I think we can keep both for RC3. For June release, we can migrate to using the meta-qcom tag as the official way of building the layer.

I'd rather understand, where that comes from and maybe keep qcom-next kernel in the wrynose branch.

Based on latest discussion, only Debian release is currently expected for Glymur. This can be reviewed again once Yocto releases are required.