Commit e46011cb authored by Jérome Perrin's avatar Jérome Perrin Committed by Rafael Monnerat

ERP5: pin neoppod git repository

It was not pinned on 1.0 branch
parent 909e8302
...@@ -5,6 +5,8 @@ extends = ...@@ -5,6 +5,8 @@ extends =
# Test Suite: ERP5-MASTER ran at 2018/03/20 11:19:53.416440 UTC # Test Suite: ERP5-MASTER ran at 2018/03/20 11:19:53.416440 UTC
# 2 failures, 1 errors, 5815 total, status: FAIL # 2 failures, 1 errors, 5815 total, status: FAIL
# .... and then missing pin for neoppod was added, so the actual status of test
# is not known, but it I (Jérome) think test status was still FAIL.
[erp5] [erp5]
revision = 7d44289405f72336f50a44e545439c6648014688 revision = 7d44289405f72336f50a44e545439c6648014688
...@@ -13,3 +15,9 @@ revision = 7d44289405f72336f50a44e545439c6648014688 ...@@ -13,3 +15,9 @@ revision = 7d44289405f72336f50a44e545439c6648014688
[cloudooo-repository] [cloudooo-repository]
revision = 0ff799ebcfea1013342f5450e88ff5c3b8536e89 revision = 0ff799ebcfea1013342f5450e88ff5c3b8536e89
branch = master branch = master
[neoppod-repository]
# 1.9
revision = 1b57a7ae0566dffc2e37f8b7d1d49e654254d701
  • Wrong place because it's possible to request a standalone NEO instance. To be moved to software/neoppod/software-common.cfg

    And rather than only tracking releases, I'd prefer if the 1.0 branch specifies the last commit of the master branch. It's enough if the hash is updated at each release of SlapOS.

    /cc @jerome @rafael @alain.takoudjou

  • mentioned in merge request !315 (merged)

    Toggle commit list
  • Thanks for the feedback @jm . For the records, this was part of !315 (merged) that was a kind of "emergency" to repair ERP5 tests suite on 1.0 failing again and again.

    I was asking myself the same question about where to put the revision. Should the version pin be in the "final" software ( allowing to have standalone NEO and ERP5 use different revision - if it makes sense ) or in the shared part, where the component is actually defined. I added it here because this seemed to be the conventions, cloudoo was also here.

    We have a doc about SlapOS Conventions. I believe we should extend it with some conventions for 1.0 branch (unless we have another doc describing the 1.0 process ?)

    /cc @rafael @alain.takoudjou

  • @jerome I think I write the conventions somewhere, but I don't know where they are.

    @jm I didn't understood the: "And rather than only tracking releases, I'd prefer if the 1.0 branch specifies the last commit of the master branch. It's enough if the hash is updated at each release of SlapOS." or you didn't understood the purpose of 1.0 branch (release candidate).

  • @jerome: Here you can learn what we do for release and 1.0 branch: https://www.erp5.com/P-ERP5.Slapos.Repository.Maintainer.Workflows

  • I didn't understood the: "And rather than only tracking releases, I'd prefer if the 1.0 branch specifies the last commit of the master branch. It's enough if the hash is updated at each release of SlapOS." or you didn't understood the purpose of 1.0 branch (release candidate).

    I mean that at the time this commit was authored, 3efbbfe3c8684342be23760fd856ef964545252d was the last revision of the NEO master branch and it should have been chosen (rather than the hash pointing to the last NEO release). I didn't know about TestResultModule_getReleaseCandidateRevision: what it returns is exactly what I want so everything's fine.

    https://www.erp5.com/P-ERP5.Slapos.Repository.Maintainer.Workflows

    Can it be made public ?

  • Now that I know the release procedure, I also agree that I should not have used tag here.

    I guess we can wit for next release candidate to correct this.

Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment