<p>As you suggested, having a build artifact to save the current commit SHA for the build would be ideal. Subsequent runs of the same workflow can download the artifact using the <a href="https://github.com/dawidd6/action-download-artifact" rel="nofollow noreferrer">dawidd6/action-download-artifact</a> action, which allows downloading artifacts generated from another workflow run.</p>
<p>Snippet for uploading artifact:</p>
<pre class="lang-yaml prettyprint-override"><code>- name: Upload artifacts
  uses: actions/upload-artifact@v2
  with:
    name: nightly-build
    path: ./COMMIT_SHA
</code></pre>
<p>Snippet for downloading the latest artifact from another workflow run:</p>
<pre class="lang-yaml prettyprint-override"><code>- name: Download artifacts
  uses: dawidd6/action-download-artifact@v2
  with:
    workflow: nightly.yml
    name: nightly-build
    path: .
</code></pre>

CC BY-SA 4.0
2021-11-17T06:51:32.600Z
A good idea, but this question is asking about [GitLab](https://gitlab.com/). [GitHub Actions](https://docs.github.com/en/actions) are specific to [GitHub](https://github.com/).
Samuel Harmer
CC BY-SA 4.0
2021-02-17T02:15:54.987Z
2021-02-17T02:15:54.987Z
Hydra
<p>Note: the answer is rather speculative, based on docs only, I didn't actually use GitLab pipelines yet.</p>
<p>You may be able to use the <a href="https://docs.gitlab.com/ee/api/pipelines.html" rel="nofollow noreferrer">Pipelines API</a>. More specifically you could <a href="https://docs.gitlab.com/ee/api/pipelines.html#get-variables-of-a-pipeline" rel="nofollow noreferrer">get a pipeline's variables</a>:</p>
<blockquote>
<p>Get variables of a pipeline</p>
<pre><code>GET /projects/:id/pipelines/:pipeline_id/variables

Attribute Type            Required    Description
id            integer/string  yes         The ID or URL-encoded path of the project owned by the authenticated user
pipeline_id   integer         yes         The ID of a pipeline
</code></pre>
<p>Example of response</p>
<pre><code>[
  {
    &quot;key&quot;: &quot;RUN_NIGHTLY_BUILD&quot;,
    &quot;variable_type&quot;: &quot;env_var&quot;,
    &quot;value&quot;: &quot;true&quot;
  },
  {
    &quot;key&quot;: &quot;foo&quot;,
    &quot;value&quot;: &quot;bar&quot;
  }
]
</code></pre>
</blockquote>
<p>I'm suspecting that in the response you'd find the variables shown in a <a href="https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline" rel="nofollow noreferrer">pipeline creation</a> response example, which include these which could be of interest to you:</p>
<blockquote>
<pre><code>  &quot;id&quot;: 61,
  &quot;sha&quot;: &quot;384c444e840a515b23f21915ee5766b87068a70d&quot;,

  &quot;before_sha&quot;: &quot;0000000000000000000000000000000000000000&quot;,
</code></pre>
</blockquote>
<p>I'm uncertain if the <code>before_sha</code> for the current pipeline is what you're looking for, if not you'd just get the <code>sha</code> for the previous pipeline ID, which you could derive from the current pipeline ID (via the <code>CI_PIPELINE_ID</code> environment variable, see <a href="https://docs.gitlab.com/ee/ci/variables/README.html#predefined-environment-variables" rel="nofollow noreferrer">Predefined environment variables</a>). I'm assuming that the pipeline IDs are consecutive.</p>

CC BY-SA 4.0
2020-02-20T08:51:36.297Z
CI_PIPELINE_ID is global to the instance and not specific to a project, CI_PIPELINE_IID would be scoped to the project but this doesn't guarantee the previous pipeline was a nightly build
Tensibai
CC BY-SA 4.0
2020-02-20T09:02:37.037Z
To complement what I said above, the approach could be ok that said by requesting the API to find the last nightly build pipeline, but it depends on how it is launched.
Tensibai
CC BY-SA 4.0
2019-09-22T20:50:10.717Z
2019-09-22T20:50:10.717Z
2020-06-18T08:28:10.803Z
Dan Cornilescu
<p>This may not be appropriate to your specific case, but I think it's worth chiming in that a general approach to &quot;generate a changelog&quot; -- especially if it's supposed to be something <em>human readable</em> would be to use <a href="https://semantic-release.gitbook.io/semantic-release/" rel="nofollow noreferrer">semantic release</a>.</p>
<p>This relies on a formal syntax in commit messages, which are then processed by <code>semantic-release</code> during the pipeline execution.</p>
<p>The <a href="https://github.com/semantic-release/changelog" rel="nofollow noreferrer">changelog plugin</a> can be used to generate the changelog, using a <a href="https://lodash.com/docs/4.17.15#template" rel="nofollow noreferrer">Lodash template</a> for the formatting. You have access to the relevant commit data in <a href="https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api#result" rel="nofollow noreferrer"><code>result</code></a> object returned by semantic release.</p>
<p>You can find a <a href="https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/gitlab-ci" rel="nofollow noreferrer">Gitlab CI example</a> at their <a href="https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations" rel="nofollow noreferrer">CI recipes</a> page:</p>
<pre><code># The release pipeline will run only if all jobs in the test pipeline are successful
stages:
  - test
  - release

before_script:
  - npm install

node:10:
  image: node:10
  stage: test
  script:
    - npm test

node:12:
  image: node:12
  stage: test
  script:
    - npm test

publish:
  image: node:12
  stage: release
  script:
    - npx semantic-release
</code></pre>
<p>If you just want to generate a changelog and not a full release object with artifacts and all, you can use the <a href="https://github.com/semantic-release/changelog" rel="nofollow noreferrer">changelog plugin</a>:</p>
<pre><code>{
  &quot;plugins&quot;: [
    &quot;@semantic-release/commit-analyzer&quot;,
    &quot;@semantic-release/release-notes-generator&quot;,
    &quot;@semantic-release/changelog&quot;,
    &quot;@semantic-release/git&quot;
  ]
}
</code></pre>

CC BY-SA 4.0
2023-03-09T08:34:10.233Z
2023-03-09T08:34:10.233Z
Bruce Becker
<p>I'm currently using Gitlab CI/CD combined with Fastlane on our build machine to perform nightly builds of an iOS app, and push those builds to TestFlight on completion. So far, so good. However, I've been asked to generate a change log of the new commits that have gone into each night's build.</p>

<p>Is it possible to get not just the <code>CI_COMMIT_SHA</code> of the current pipeline run, but also the SHA of the previous commit that the pipeline last ran for? That way, I could generate a change log of what's new in the current pipeline run? After searching the docs on Gitlab.com, I'm coming up empty so far.</p>

<p>As part of the pipeline, we also generate a build manifest that includes the current commit SHAs used for the build, and save that as an artifact. So, if it was possible to download the most recent artifacts, I could also maybe just look at that manifest, but again, I'm not seeing a way to do that either.</p>

CC BY-SA 4.0
2020-02-20T08:53:55.220Z
Won't you have pipeline runs between the nightly builds ? The easier way seems to commit back the repo with a last_night_build file containing the current sha after computing the change log from it.
Tensibai
<gitlab><gitlab-ci-runner>
GitLab CI/CD: How do I generate a change log between pipeline runs?
Josh Buhler
# GitLab CI/CD: How do I generate a change log between pipeline runs?

(Asked by: username_0 on 2019-09-19)

I'm currently using Gitlab CI/CD combined with Fastlane on our build machine to perform nightly builds of an iOS app, and push those builds to TestFlight on completion. So far, so good. However, I've been asked to generate a change log of the new commits that have gone into each night's build.

Is it possible to get not just the `CI_COMMIT_SHA` of the current pipeline run, but also the SHA of the previous commit that the pipeline last ran for? That way, I could generate a change log of what's new in the current pipeline run? After searching the docs on Gitlab.com, I'm coming up empty so far.

As part of the pipeline, we also generate a build manifest that includes the current commit SHAs used for the build, and save that as an artifact. So, if it was possible to download the most recent artifacts, I could also maybe just look at that manifest, but again, I'm not seeing a way to do that either.

**Tags:** gitlab, gitlab-ci-runner

> **Comments:**
> **username_1**: Won't you have pipeline runs between the nightly builds ? The easier way seems to commit back the repo with a last_night_build file containing the current sha after computing the change log from it.  

---

## 3 answers

### Answer by username_2 on 2021-02-17. Score: 0

As you suggested, having a build artifact to save the current commit SHA for the build would be ideal. Subsequent runs of the same workflow can download the artifact using the dawidd6/action-download-artifact action, which allows downloading artifacts generated from another workflow run.
Snippet for uploading artifact:
- name: Upload artifacts
  uses: actions/upload-artifact@v2
  with:
    name: nightly-build
    path: ./COMMIT_SHA

Snippet for downloading the latest artifact from another workflow run:
- name: Download artifacts
  uses: dawidd6/action-download-artifact@v2
  with:
    workflow: nightly.yml
    name: nightly-build
    path: .

> **Comments:**
> **username_3**: A good idea, but this question is asking about [GitLab](https://gitlab.com/). [GitHub Actions](https://docs.github.com/en/actions) are specific to [GitHub](https://github.com/).  

---

### Answer by username_4 on 2019-09-22. Score: 0

Note: the answer is rather speculative, based on docs only, I didn't actually use GitLab pipelines yet.
You may be able to use the Pipelines API. More specifically you could get a pipeline's variables:

Get variables of a pipeline
GET /projects/:id/pipelines/:pipeline_id/variables

Attribute Type            Required    Description
id            integer/string  yes         The ID or URL-encoded path of the project owned by the authenticated user
pipeline_id   integer         yes         The ID of a pipeline

Example of response
[
  {
    "key": "RUN_NIGHTLY_BUILD",
    "variable_type": "env_var",
    "value": "true"
  },
  {
    "key": "foo",
    "value": "bar"
  }
]


I'm suspecting that in the response you'd find the variables shown in a pipeline creation response example, which include these which could be of interest to you:

  "id": 61,
  "sha": "384c444e840a515b23f21915ee5766b87068a70d",

  "before_sha": "0000000000000000000000000000000000000000",


I'm uncertain if the before_sha for the current pipeline is what you're looking for, if not you'd just get the sha for the previous pipeline ID, which you could derive from the current pipeline ID (via the CI_PIPELINE_ID environment variable, see Predefined environment variables). I'm assuming that the pipeline IDs are consecutive.

> **Comments:**
> **username_1**: CI_PIPELINE_ID is global to the instance and not specific to a project, CI_PIPELINE_IID would be scoped to the project but this doesn't guarantee the previous pipeline was a nightly build  
> **username_1**: To complement what I said above, the approach could be ok that said by requesting the API to find the last nightly build pipeline, but it depends on how it is launched.  

---

### Answer by username_5 on 2023-03-09. Score: 0

This may not be appropriate to your specific case, but I think it's worth chiming in that a general approach to "generate a changelog" -- especially if it's supposed to be something human readable would be to use semantic release.
This relies on a formal syntax in commit messages, which are then processed by semantic-release during the pipeline execution.
The changelog plugin can be used to generate the changelog, using a Lodash template for the formatting. You have access to the relevant commit data in result object returned by semantic release.
You can find a Gitlab CI example at their CI recipes page:
# The release pipeline will run only if all jobs in the test pipeline are successful
stages:
  - test
  - release

before_script:
  - npm install

node:10:
  image: node:10
  stage: test
  script:
    - npm test

node:12:
  image: node:12
  stage: test
  script:
    - npm test

publish:
  image: node:12
  stage: release
  script:
    - npx semantic-release

If you just want to generate a changelog and not a full release object with artifacts and all, you can use the changelog plugin:
{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/git"
  ]
}


---

