Issue #1226: Redefine default branch for ref: - fm-orchestrator

fm-orchestrator

#1226 Redefine default branch for ref:

Closed: Duplicate 2 years ago by mikem. Opened 4 years ago by vondruch.

This was originally reported here [0], but I was asked to open ticket here, so here we go.

The ref: [1] is defined as follows:

# Use this specific commit hash, branch name or tag for
# the build.  If ref is a branch name, the branch HEAD
# will be used.  If no ref is given, the master branch
# is assumed.

However to choose "master" as a default is completely wrong. This does not work and this does not work especially in RHEL, where there are used maintenance branches. Let me explain.

In RHEL, it is quite common to maintain version specific branches, e.g. rhel-8.0.0, rhel-8.1.0, etc. Lets say I have module foo, which refers to some other module, e.g.:

... snip ...

    components:
        # SRPMs
        rpms:
            bar:
                rationale: Dependnecy.
                ref: stream-foo-8.0.0

... snip ...

Now with the move to RHEL 8.1.0 development, I would need to change the module file every time? That does not make any sense. It is fragile and error prone. This must be changed IMO.

Whatever the name of the branch is in module repository, the same branch must be used for the referred components. If there is not branch like this for the specified component, then master is used.

Please note that this also relates to suggested branching model and to this discussion [2].

psabata commented 4 years ago

What you're suggesting wouldn't work for RHEL either as the branching schema differes between the modules and rpms namespaces. You will have to define ref.

One way to make the maintainers' lives easier would be adjusting the modulemd files at branch point. That would be a Red Hat internal process, however.

vondruch commented 4 years ago

What you're suggesting wouldn't work for RHEL either as the branching schema differes between the modules and rpms namespaces.

This was only deliberate choice AFAIU, nothing which should not be changed.

One way to make the maintainers' lives easier would be adjusting the modulemd files at branch point. That would be a Red Hat internal process, however.

Yes, that would be possible workaround, but wrong solution.

mprahl commented 4 years ago

@vondruch thank you for submitting this RFE, but this needs to be a change that is coordinated with MBS, the Modularity team, and all module packagers. Our team doesn't have the bandwidth to pursue this at the moment. I'll drop this RFE until we get a direct ask from @psabata about implementing this.

Metadata Update from @mprahl:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

4 years ago

ppisar commented 2 years ago

coordinated with MBS

That's this ticket. You should be also interested in https://pagure.io/fm-orchestrator/issue/1735 which tries to remove all hard-coded references to master from MBS.

Modularity team

Modularity specification has already been relaxed to accept any default value as an implementation detail https://github.com/fedora-modularity/libmodulemd/pull/501. I think MBS is not restrained by the policy any more.

We have the same discussion in modularity https://pagure.io/modularity/issue/142.

and all module packagers

Nowdays, no module in Fedora 36 uses undefined ref. Probably because MBS defaults to master branch which does not exist in Fedora's dist-git any more so it's completely useless.