Skip to content

Commit 22c353f

Browse files
v1vSergeyKleyman
v1v
authored and
SergeyKleyman
committed
[CI] automate release process
1 parent d98c0b4 commit 22c353f

File tree

8 files changed

+276
-4
lines changed

8 files changed

+276
-4
lines changed

‎.ci/.gren.js

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
module.exports = {
2+
"username": "elastic",
3+
"repo": "ecs-logging-php",
4+
"dataSource": "prs",
5+
"ignoreIssuesWith": [
6+
"automation",
7+
"ci",
8+
"developer only"
9+
],
10+
"groupBy": {
11+
"Breaking changes": ["breaking"],
12+
"Bug fixes": ["bug", "fix"],
13+
"Features": ["enhancement", "feature", "feat"]
14+
},
15+
"template": {
16+
commit: ({ message, url, author, name }) => `- [${message}](${url}) - ${author ? `@${author}` : name}`,
17+
issue: "- {{labels}} {{name}} [{{text}}]({{url}})",
18+
label: "[**{{label}}**]",
19+
noLabel: "closed",
20+
changelogTitle: "# Changelog\n\n",
21+
release: "## {{release}} ({{date}})\n{{body}}",
22+
releaseSeparator: "\n---\n\n",
23+
group: function (placeholders) {
24+
return '\n#### ' + placeholders.heading + '\n';
25+
}
26+
}
27+
}

‎.ci/Jenkinsfile

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ pipeline {
99
BASE_DIR = "src/go.elastic.co/apm/${env.REPO}"
1010
NOTIFY_TO = credentials('notify-to')
1111
JOB_GCS_BUCKET = credentials('gcs-bucket')
12+
SLACK_CHANNEL = '#apm-agent-php'
1213
}
1314
options {
1415
timeout(time: 1, unit: 'HOURS')
@@ -64,6 +65,54 @@ pipeline {
6465
}
6566
}
6667
}
68+
stage('Release') {
69+
options {
70+
skipDefaultCheckout()
71+
timeout(time: 12, unit: 'HOURS')
72+
}
73+
when {
74+
beforeAgent true
75+
tag pattern: 'v\\d+.*', comparator: 'REGEXP'
76+
}
77+
agent { label 'docker && ubuntu-18.04 && immutable' }
78+
environment {
79+
RELEASE_URL_MESSAGE = "(<https://github.com/elastic/${env.REPO}/releases/tag/${env.TAG_NAME}|${env.TAG_NAME}>)"
80+
}
81+
stages {
82+
stage('Notify') {
83+
options { skipDefaultCheckout() }
84+
steps {
85+
notifyStatus(slackStatus: 'warning', subject: "[${env.REPO}] Release ready to be pushed",
86+
body: "Please (<${env.BUILD_URL}input|approve>) it or reject within 12 hours.\n Changes: ${env.TAG_NAME}")
87+
}
88+
}
89+
stage('Release CI') {
90+
options { skipDefaultCheckout() }
91+
steps {
92+
deleteDir()
93+
unstash 'source'
94+
dir("${BASE_DIR}") {
95+
withCredentials([string(credentialsId: '2a9602aa-ab9f-4e52-baf3-b71ca88469c7', variable: 'GITHUB_TOKEN')]) {
96+
sh(script: 'make -f .ci/Makefile release', label: 'release')
97+
}
98+
}
99+
}
100+
}
101+
}
102+
post {
103+
failure {
104+
notifyStatus(slackStatus: 'danger', subject: "[${env.REPO}] Release *${env.TAG_NAME}* failed", body: "Build: (<${env.RUN_DISPLAY_URL}|here>)")
105+
}
106+
success {
107+
notifyStatus(slackStatus: 'good', subject: "[${env.REPO}] Release *${env.TAG_NAME}* published", body: "Build: (<${env.RUN_DISPLAY_URL}|here>)\nRelease URL: ${env.RELEASE_URL_MESSAGE}")
108+
}
109+
always {
110+
script {
111+
currentBuild.description = "${currentBuild.description?.trim() ? currentBuild.description : ''} released"
112+
}
113+
}
114+
}
115+
}
67116
}
68117
post {
69118
cleanup {
@@ -95,3 +144,11 @@ def buildWithGitHubNotification(version){
95144
build(version)
96145
}
97146
}
147+
148+
def notifyStatus(def args = [:]) {
149+
slackSend(channel: env.SLACK_CHANNEL, color: args.slackStatus, message: "${args.subject}. ${args.body}",
150+
tokenCredentialId: 'jenkins-slack-integration-token')
151+
// transform slack URL format '(<URL|description>)' to 'URL'.
152+
def bodyEmail = args.body.replaceAll('\\(<', '').replaceAll('\\|.*>\\)', '')
153+
emailext(subject: args.subject, to: "${env.NOTIFY_TO}", body: bodyEmail)
154+
}

‎.ci/Makefile

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
SHELL=/bin/bash -o pipefail
2+
3+
CURRENT_UID := $(shell id -u)
4+
CURRENT_GID := $(shell id -g)
5+
6+
.PHONY: help
7+
.DEFAULT_GOAL := help
8+
help: ## Display this help text
9+
@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'
10+
11+
.PHONY: prepare-release
12+
prepare-release: ## Prepare the dependencies to run the release
13+
@docker build --tag gren -f .ci/docker/gren/Dockerfile .
14+
15+
.PHONY: release
16+
release: prepare-release ## Run a release given the GITHUB_TOKEN and TAG_NAME
17+
ifndef GITHUB_TOKEN
18+
@echo "Please set GITHUB_TOKEN in the environment to generate the changelog"
19+
exit 1
20+
endif
21+
ifndef TAG_NAME
22+
@echo "Please set TAG_NAME in the environment to create the changelog"
23+
exit 1
24+
endif
25+
@docker run --rm -t \
26+
--volume "$(PWD)":/app \
27+
--workdir /app \
28+
--env GITHUB_TOKEN=$(GITHUB_TOKEN) \
29+
--env TAG_NAME=$(TAG_NAME) \
30+
-u $(CURRENT_UID):$(CURRENT_GID) \
31+
gren

‎.ci/docker/gren/Dockerfile

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
FROM node:14.5.0-stretch-slim
2+
3+
RUN apt-get update -qq -y \
4+
&& apt-get install -qq -y --no-install-recommends git \
5+
&& rm -rf /var/lib/apt/lists/*
6+
7+
RUN npm install github-release-notes@0.17.3 -g
8+
WORKDIR /app
9+
10+
ENTRYPOINT [ "/app/.ci/docker/gren/entrypoint.sh" ]

‎.ci/docker/gren/entrypoint.sh

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
#!/usr/bin/env bash
2+
set -exo pipefail
3+
4+
/usr/local/bin/gren release \
5+
--token="${GITHUB_TOKEN}" \
6+
--tags="${TAG_NAME}" \
7+
--config .ci/.grenrc.js

‎CONTRIBUTING.md

Lines changed: 126 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,126 @@
1+
# Contributing to the ECS Logging for PHP
2+
3+
The ECS Logging for PHP is open source and we love to receive contributions from our community — you!
4+
5+
There are many ways to contribute,
6+
from writing tutorials or blog posts,
7+
improving the documentation,
8+
submitting bug reports and feature requests or writing code.
9+
10+
You can get in touch with us through [Discuss](https://discuss.elastic.co/c/apm),
11+
feedback and ideas are always welcome.
12+
13+
## Code contributions (please read this before your first PR)
14+
15+
If you have a bugfix or new feature that you would like to contribute,
16+
please find or open an issue about it first.
17+
Talk about what you would like to do.
18+
It may be that somebody is already working on it,
19+
or that there are particular issues that you should know about before implementing the change.
20+
21+
We aim to maintain high code quality, therefore every PR goes through the same review process, no matter who opened the PR.
22+
23+
### General advice
24+
25+
Please make sure that your PR addresses a single issue and its size is reasonable to review. There are no hard rules, but please keep in mind that every line of your PR will be reviewed and it's not uncommon that a longer discussion evolves in case of a sensitive change.
26+
27+
Therefore it's preferred to have multiple smaller PRs over a single big PR.
28+
29+
This makes sure that changes that have consensus get merged quickly and don't get blocked by unrelated changes. Additionally, the repository will also have a useful and searchable history by doing so.
30+
31+
Please do:
32+
- Try to get feedback as early as possible and prefer to ask questions in issues before you start submitting code.
33+
- Add a description to your PR which describes your intention and gives a high level summary about your changes.
34+
- Run all the tests from the `tests` folder and make sure that all of them are green. See [Testing](###Testing).
35+
- In case of new code, make sure it's covered by at least 1 test.
36+
- make sure your IDE uses the `.editorconfig` from the repo and you follow our coding guidelines. See [Coding-guidelines](###Coding-guidelines).
37+
- Feel free to close a PR and create a new one in case you changed your mind, or found a better solution.
38+
- Feel free to fix typos.
39+
- Feel free to use the draft PR feature of GitHub, in case you would like to show some work in progress code and get feedback on it.
40+
41+
Please don't:
42+
- Create a PR where you address multiple issues at once.
43+
- Create a giant PR with a huge change set. There is no hard rule, but if your change grows over 1000 lines, it's maybe worth thinking about making it self contained and submit it as a PR and address follow-up issues in a subsequent PR. (of course there can be exceptions)
44+
- Actively push code to a PR until you have received feedback. Of course if you spot some minor things after you opened a PR, it's perfectly fine to push a small fix. But please don't do active work on a PR that haven't received any feedback. It's very possible that someone already looked at it and is about to write a detailed review. If you actively add new changes to a PR then the reviewer will have a hard time to provide up to date feedback. If you just want to show work-in-progress code, feel free to use the draft feature of github, or indicate in the title, that the work is not 100% done yet. Of course, once you have feedback on a PR, it's perfectly fine, or rather encouraged to start working collaboratively on the PR and push new changes and address issues and suggestions from the reviewer.
45+
- Change or add dependencies, unless you are really sure about it (it's best to ask about this in an issue first) - see [compatibility](####compatibility).
46+
47+
### Submitting your changes
48+
49+
Generally, we require that you test any code you are adding or modifying.
50+
Once your changes are ready to submit for review:
51+
52+
1. Sign the Contributor License Agreement
53+
54+
Please make sure you have signed our [Contributor License Agreement](https://www.elastic.co/contributor-agreement/).
55+
We are not asking you to assign copyright to us,
56+
but to give us the right to distribute your code without restriction.
57+
We ask this of all contributors in order to assure our users of the origin and continuing existence of the code.
58+
You only need to sign the CLA once.
59+
60+
2. Build and package your changes
61+
62+
Run the build and package goals to make sure that nothing is broken.
63+
See [development](#development) for details.
64+
65+
3. Test your changes
66+
67+
Run the test suite to make sure that nothing is broken.
68+
See [testing](#testing) for details.
69+
70+
4. Rebase your changes
71+
72+
Update your local repository with the most recent code from the main repo,
73+
and rebase your branch on top of the latest master branch.
74+
We prefer your initial changes to be squashed into a single commit.
75+
Later,
76+
if we ask you to make changes,
77+
add them as separate commits.
78+
This makes them easier to review.
79+
As a final step before merging, we will either ask you to squash all commits yourself or we'll do it for you.
80+
81+
5. Submit a pull request
82+
83+
Push your local changes to your forked copy of the repository and [submit a pull request](https://help.github.com/articles/using-pull-requests).
84+
In the pull request,
85+
choose a title which sums up the changes that you have made,
86+
and in the body provide more details about what your changes do.
87+
Also mention the number of the issue where the discussion has taken place,
88+
eg "Closes #123".
89+
90+
6. Be patient
91+
92+
We might not be able to review your code as fast as we would like to,
93+
but we'll do our best to dedicate it the attention it deserves.
94+
Your effort is much appreciated!
95+
96+
### Development
97+
98+
Coming soon [TBD]
99+
100+
### Testing
101+
102+
```bash
103+
composer test
104+
```
105+
106+
### Workflow
107+
108+
All feature development and most bug fixes hit the master branch first.
109+
Pull requests should be reviewed by someone with commit access.
110+
Once approved, the author of the pull request,
111+
or reviewer if the author does not have commit access,
112+
should "Squash and merge".
113+
114+
### Design considerations
115+
116+
#### Compatibility
117+
118+
Coming soon [TBD]
119+
120+
### Coding guidelines
121+
122+
Coming soon [TBD]
123+
124+
### Releasing
125+
126+
See [RELEASE.md](RELEASE.md) for details on releasing.

‎README.md

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -31,10 +31,9 @@ composer require elastic/ecs-logging
3131
* Introduction to ECS [blog post](https://www.elastic.co/blog/introducing-the-elastic-common-schema).
3232
* Logs UI [blog post](https://www.elastic.co/blog/infrastructure-and-logs-ui-new-ways-for-ops-to-interact-with-elasticsearch).
3333

34-
## Test
35-
```
36-
composer test
37-
```
34+
## Contributing
35+
36+
See [contributing documentation](CONTRIBUTING.md).
3837

3938
## License
4039
This software is licensed under the [Apache 2 license](https://github.com/elastic/ecs-logging-php/blob/master/LICENSE).

‎RELEASE.md

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
# Releasing
2+
3+
## CI based
4+
5+
The release process is also automated in the way any specific commit, from the master branch ideally, can be potentially released, for such it's required the below steps:
6+
7+
1. Checkout the commit to be released
8+
1. Create a tag with the format `v.[0-9]+.[0-9]+.[0-9]+`, i.e.: `v1.0.2`
9+
1. Push the tag to the upstream.
10+
1. Then, the CI pipeline will trigger a release.
11+
1. Wait for an email/slack to confirm the release is ready to be approved, it might take roughly 20 minutes.
12+
1. Login to apm-ci.elastic.co
13+
1. Click on the URL from the email/slack.
14+
1. Click on approve or abort.
15+
1. Then you can go to the `https://packagist.org/packages/elastic/ecs-logging` and [GitHub releases](https://github.com/elastic/ecs-logging-php/releases) to validate that the bundles and release notes have been published.

0 commit comments

Comments
 (0)