Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
CI_Source CI_Source
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Labels
    • Labels
  • Merge requests 5
    • Merge requests 5
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Metrics
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Jobs
  • Commits
Collapse sidebar
  • Support
  • CI_SourceCI_Source
  • Merge requests
  • !26

Open
Created Jul 08, 2022 by Ben Avison@bavisonDeveloper
  • Report abuse
Report abuse

Draft: When accepting a merge request, include VersionNum updates in binaries

  • Overview 0
  • Commits 1
  • Pipelines 3
  • Changes 1

At this point, GitLab launches a non-detached pipeline, but does so using the SHA from before srccommit did its thing to update the VersionNum (because this is performed using a hook at the git level that GitLab knows nothing about). The result is that the last artifacts presented on the MR page still have the version numbers at their pre-increment state. It's still possible to autobuild binaries with the new version number by manually launching a pipeline afterwards, but that's an extra step for a human to perform and so is undesirable.

To attempt to deal with this, introduce a check on the environment variable CI_COMMIT_BRANCH. This is only set when the pipeline was launched based on a branch ref, and appears to include the case when an MR has just been merged. If so, we assume the origin remote contains a more up-to-date version of this branch ref (i.e. one with VersionNum updated) so we check that out before commencing the rest of the build steps.

When launching a pipeline manually on a branch ref, this additional step should have no effect.

I definitely think it's worth testing this MR on an offline GitLab installation before merging it - can you help with this @jbyrne? It's just the sort of thing I can imagine GitLab screwing up, especially with a forked workflow, for example in cases where the same branch ref exists (pointing at different commits) in the fork project vs the upstream project.

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: incorporate-versionnum-updates