Should we prevent adding packages to CHaP from non-master branches

[erikd]

For the sake of reproducible builds we probably want to avoid uploading to CHaP from ephemeral PR branches and probably also non-master branches.

In db-sync we have a check for source-repository-package git hashes here.

[erikd]

Yes, master branches can be force pushed, but that should be avoided as much as possible.

[andreabedini]

Given a commit hash we don't really have any guarantee that it is not going to be gc'ed. Any branch can be deleted or force pushed, any repo can be deleted. I understand this should not happen but ... what if it does happen 🤷

As much as your suggestion sounds like a good idea, I am wondering what scenario do we want to avoid?

E.g. The scenario in which a package is accidentally uploaded with a commit that does not belong to any branch (and therefore risk being gc'ed) could be fixed by creating a branch for that commit.

What other scenarios do you have in mind?

[erikd]

As much as your suggestion sounds like a good idea, I am wondering what scenario do we want to avoid?

We have already had at least one instance of the node using an s-r-p git hash from a PR branch. The commit hash being referred to disappeared when the PR was merged. We want to avoid this.

fixed by creating a branch for that commit.

Its still extra work, whereas we can prevent it happening over 95+% of the time by requiring master branch commits. We should also strongly discourage force pushing to the master branch of code repositories.

[michaelpj]

What about release branches? It's common to do at least patch releases from release branches, and if that involves cherry-picking commits then the released commit will exist only on the release branch. We can try and guess if it's on a release branch, but that seems error-prone.

I guess maybe what we want is a warning if it's not on master? "This commit does not come from master, but is present on release/1.x, please double check that this is what you want and that this branch will continue to exist in future"?

[ch1bo]

I like the idea of the warning, but then we need to take care we now what the right "trunk" (master/main/release/...) branch is to check against for each package, right?

What about tags? They're quite "sticky" (not pulled/updated the same as branch refs IIRC) and commonly used to mark a release.

I would like to see a warning if something added to CHaP is not tagged on the source repository.

[michaelpj]

At the moment we don't have package-level metadata, but we could. You could imagine putting stuff in the package metadata like "these are the acceptable source repositories you can fetch versions from" or "versions must be tagged with a tag matching a particular pattern" or something. But maybe that's getting too fancy.