|
| 1 | +--- |
| 2 | +title: "Automating dev-sec releases with Github Actions" |
| 3 | +date: 2020-05-30 09:00:00 |
| 4 | +authors: |
| 5 | +- name: Sebastian Gumprich |
| 6 | + image: https://avatars0.githubusercontent.com/u/3198961?v=4 |
| 7 | + link: https://www.zufallsheld.de |
| 8 | +--- |
| 9 | + |
| 10 | +Hey friends, |
| 11 | + |
| 12 | +some time ago someone who uses our Ansible roles created an [issue](https://github.com/dev-sec/ansible-os-hardening/issues/269) in our ansible-os-hardening role stating that the readme in the Ansible Galaxy diverged from the actual releases you can find on Galaxy. |
| 13 | +The reason for that is simple: Galaxy shows the from the master-branch in the Github-repository - *not* from the latest release that is uploaded there. |
| 14 | +That produced a discrepancy between the functions of the role and what is described in the readme. |
| 15 | +Since I did not have time to create a new release for os-hardening (it was done manually at the time), the contents diverged quite heavily. |
| 16 | + |
| 17 | +This real and important problem lead me to automating the releases of the Ansible roles. |
| 18 | + |
| 19 | +Our manual workflow consisted of (1) updating the CHANGELOG with the [github-changelog-generator](https://github.com/github-changelog-generator/github-changelog-generator), (2) finding out what the next version number should be by looking at the PRs, then (3) creating a new tag with this version number and finally (4) releasing a new version of Github. Ansible Galaxy then automatically published a new version from the Github release. |
| 20 | + |
| 21 | +My requirements for automating this where: |
| 22 | + |
| 23 | +* keep the CHANGELOG and continue using the generator since it works pretty well |
| 24 | +* The release version should be automatically decided upon, based on the PRs |
| 25 | +* A Release draft should be created that I then can check and publish manually |
| 26 | + |
| 27 | +I then started experimenting with Github Actions (since I hadn't worked with it before and wanted to try it). |
| 28 | +I searched the Actions Marketplace for Actions that could help me accomplish my goal. |
| 29 | + |
| 30 | +The initial Action only created and pushed a changelog every time a new PR was merged, issued were closed or releases published: |
| 31 | + |
| 32 | +``` |
| 33 | +name: Changelog |
| 34 | +
|
| 35 | +on: |
| 36 | + pull_request: |
| 37 | + types: [closed] |
| 38 | +
|
| 39 | + release: |
| 40 | + types: [published] |
| 41 | +
|
| 42 | + issues: |
| 43 | + types: [closed, edited] |
| 44 | +
|
| 45 | +jobs: |
| 46 | + generate_changelog: |
| 47 | + runs-on: ubuntu-latest |
| 48 | + name: Generate changelog for master branch |
| 49 | + steps: |
| 50 | + - uses: actions/checkout@v1 |
| 51 | +
|
| 52 | + - name: Generate changelog |
| 53 | + uses: charmixer/auto-changelog-action@v1 |
| 54 | + with: |
| 55 | + token: ${{ secrets.GITHUB_TOKEN }} |
| 56 | +
|
| 57 | + - name: push |
| 58 | + uses: github-actions-x/commit@v2.6 |
| 59 | + with: |
| 60 | + github-token: ${{ secrets.GITHUB_TOKEN }} |
| 61 | + push-branch: 'changelog' |
| 62 | + commit-message: 'update changelog' |
| 63 | + force-add: 'true' |
| 64 | + files: CHANGELOG.md |
| 65 | + name: dev-sec CI |
| 66 | + email: hello@dev-sec.io |
| 67 | +``` |
| 68 | + |
| 69 | +I continued experimenting and created a second action that did: |
| 70 | + |
| 71 | +- get the previous tag (to generate the changelog from this tag) |
| 72 | +- get the next tag with the help of labels on PRs (major, minor, patch) |
| 73 | +- generate a changelog |
| 74 | +- create a release draft with the generated changelog and the release- and tag-name of the next tag |
| 75 | + |
| 76 | +You can find the code here: https://github.com/rndmh3ro/ansible-os-hardening/blob/7.0.0/.github/workflows/release.yml |
| 77 | + |
| 78 | +So now I had two actions: one for creating a continously updated changelog and one for creating release drafts. I was fine with this for now. |
| 79 | + |
| 80 | +Then [@micheelengronne](https://github.com/micheelengronne) picked up my work and continued improving the Action. He applied the Action on our Inspec baselines and unified the two actions into one. You can find the code here: https://github.com/dev-sec/ssl-baseline/actions/runs/109370590/workflow |
| 81 | + |
| 82 | +So now all our Inspec-baselines and Ansible-roles have almost-automatic releases: whenever someone merges a PR, a release-draft is created containing the changes in a nicely formatted changelog - ready to be released by the push of a button! |
0 commit comments