Feature change: charm-build --use-lock-file-branches shouldn't use master branch #605
Closed
3 tasks done
Assignees
Comments
ajkavanagh
added a commit
to ajkavanagh/charm-tools
that referenced
this issue
Apr 9, 2021
When the --use-lock-file-branches option was used, several bugs were discovered in more complicated charms. * Using the master branch as a tracking branch was the wrong idea. Instead, if the master branch is set in the lock file for a layer or python module, then the commit hash is used instead. Use --ignore-lock-file to be able to just use master branches. Bug juju#605 * Detection of branches from a repository is just not possible in practice. So remove the feature and (for compatibility with the build from 2.8.3 lockfiles) use the commit hash instead for the branch. * For python modules use the revision, as detected by th revision-parser module, as the locked revision.
3 tasks
ajkavanagh
added a commit
to ajkavanagh/charm-tools
that referenced
this issue
Sep 16, 2022
When the --use-lock-file-branches option was used, several bugs were discovered in more complicated charms. * Using the master branch as a tracking branch was the wrong idea. Instead, if the master branch is set in the lock file for a layer or python module, then the commit hash is used instead. Use --ignore-lock-file to be able to just use master branches. Bug juju#605 * Detection of branches from a repository is just not possible in practice. So remove the feature and (for compatibility with the build from 2.8.3 lockfiles) use the commit hash instead for the branch. * For python modules use the revision, as detected by th revision-parser module, as the locked revision.
|
Fixed by #607 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checklist
What version am I running?
I ran the following command:snap info charmand got the following ouput:charm-tools 2.8.3 from PyPi
I am using: Ubuntu 20.04
Issue/Feature
When a charm is rebuilt with
--use-lock-file-branchesit also uses therefs/heads/masterbranch rather than using the commit hash. This isn't really what is wanted, I'd hazard a guess (especially as I wrote the feature!)The idea was that anything that was from a branch would track that branch, but that anything on the master (and I guess 'main') branch would be pinned to the commit hash. But that's not what happened.
I expect/expected the following
The master branch would be ignored, and it would select the commit hash.
What I got
It selects the master branch, rather than the commit hash.
Proposal
So the principle development branch for git is
master(or more recently, alsomain). My proposal is to pick the commit hash if the branch in thebuild.lockfile isrefs/heads/masterorrefs/heads/main. This will then build the charm according to the stable branches and (if they are not available) commit hashes.The text was updated successfully, but these errors were encountered: