[Starlingx-discuss] Updating SHA pointers in build system.
Hi all, In preparation to open source, some components of StarlingX were squashed, this causes that the git history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components as now points to missing commits, causing a broken build. My question is what to do with these variables, should we: - Update to a valid commit - Set the variable value to HEAD - Remove those variables, not sure if that's possible. What do you think is the best course of action. -Erich
On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote:
In preparation to open source, some components of StarlingX were squashed, this causes that the git history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components as now points to missing commits, causing a broken build.
Erich, do you know why they were pointing directly at a commit and not using a tag or branch? It sounds like that is a per-package variable? If it was a global this could be fun to fix with the now-split repos.
My question is what to do with these variables, should we:
- Update to a valid commit - Set the variable value to HEAD - Remove those variables, not sure if that's possible.
What do you think is the best course of action.
We'll have to let WRS weigh in here as to the purpose and solution. dt -- Dean Troyer dtroyer@gmail.com
For patching purposes, it's required that either the package version, or the release number increment with every commit. TIS_BASE_SRCREV is part of a mechanism to automatically set the release number by counting commits from a reference commit. TIS_BASE_SRCREV is the reference commit. It should point to a valid sha on the current branch. A tag would also be acceptable, although I don't know if we've ever tested with a tag. TIS_SRC_REV should be reset every time the openstack component declares a new version. Scott Little On 18-06-18 10:12 AM, Dean Troyer wrote:
On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote:
In preparation to open source, some components of StarlingX were squashed, this causes that the git history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components as now points to missing commits, causing a broken build. Erich, do you know why they were pointing directly at a commit and not using a tag or branch? It sounds like that is a per-package variable? If it was a global this could be fun to fix with the now-split repos.
My question is what to do with these variables, should we:
- Update to a valid commit - Set the variable value to HEAD - Remove those variables, not sure if that's possible.
What do you think is the best course of action. We'll have to let WRS weigh in here as to the purpose and solution.
dt
Ok, I'll update the missing references on these components. ceph/centos/build_srpm.data devtools/qemu/centos/build_srpm.data openstack/openstack-ras/centos/build_srpm.data openstack/python-ceilometerclient/centos/build_srpm.data openstack/python-openstacksdk/centos/build_srpms.data Thanks. Erich On 6/18/18, 9:40 AM, "Scott Little" <scott.little@windriver.com> wrote: For patching purposes, it's required that either the package version, or the release number increment with every commit. TIS_BASE_SRCREV is part of a mechanism to automatically set the release number by counting commits from a reference commit. TIS_BASE_SRCREV is the reference commit. It should point to a valid sha on the current branch. A tag would also be acceptable, although I don't know if we've ever tested with a tag. TIS_SRC_REV should be reset every time the openstack component declares a new version. Scott Little On 18-06-18 10:12 AM, Dean Troyer wrote: > On Sun, Jun 17, 2018 at 9:13 AM, Cordoba Malibran, Erich > <erich.cordoba.malibran@intel.com> wrote: >> In preparation to open source, some components of StarlingX were squashed, this causes that the git >> history is different now. Therefore, the TIS_BASE_SRCREV variable is broken for several components >> as now points to missing commits, causing a broken build. > Erich, do you know why they were pointing directly at a commit and not > using a tag or branch? It sounds like that is a per-package variable? > If it was a global this could be fun to fix with the now-split repos. > >> My question is what to do with these variables, should we: >> >> - Update to a valid commit >> - Set the variable value to HEAD >> - Remove those variables, not sure if that's possible. >> >> What do you think is the best course of action. > We'll have to let WRS weigh in here as to the purpose and solution. > > dt > _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Mon, Jun 18, 2018 at 11:09 AM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote:
Ok, I'll update the missing references on these components.
ceph/centos/build_srpm.data devtools/qemu/centos/build_srpm.data openstack/openstack-ras/centos/build_srpm.data openstack/python-ceilometerclient/centos/build_srpm.data openstack/python-openstacksdk/centos/build_srpms.data
Ah, they are all upstream repos on github. We could tag the squash commit as a starting point (there is one for the upstream parent to the squash commit, stx-r1-upstream) if that would be helpful. dt -- Dean Troyer dtroyer@gmail.com
I had a look at the tools. A tag should work. stx-r1-upstream is our tag for the upstream PARENT of the first STX commit? That's good to know, and yes we should be consistent across all upstream gits. On 18-06-18 01:29 PM, Dean Troyer wrote:
Ok, I'll update the missing references on these components.
ceph/centos/build_srpm.data devtools/qemu/centos/build_srpm.data openstack/openstack-ras/centos/build_srpm.data openstack/python-ceilometerclient/centos/build_srpm.data openstack/python-openstacksdk/centos/build_srpms.data Ah, they are all upstream repos on github. We could tag the squash commit as a starting point (there is one for the upstream parent to
On Mon, Jun 18, 2018 at 11:09 AM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote: the squash commit, stx-r1-upstream) if that would be helpful.
dt
participants (3)
-
Cordoba Malibran, Erich
-
Dean Troyer
-
Scott Little