Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: what the CI does #3599

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs: what the CI does #3599

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f885dcc
docs: what the CI does
v1v Aug 31, 2023
4b75a76
Update .github/workflows/README.md
v1v Sep 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions .github/workflows/README.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before I give feedback on the content here, the https://github.com/elastic/apm-agent-nodejs/blob/main/TESTING.md file documents most of this.

Is there a strong desire to have this file? Who is the audience?

(TESTING.md currently doesn't discuss snapshot.yml, opentelemetry.yml, and microbenchmark.yml, but I could easily do so if that would mean we could avoid this file. I'd like to avoid having duplicate docs, unless there is a particular need for a different audience.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before I give feedback on the content here, the https://github.com/elastic/apm-agent-nodejs/blob/main/TESTING.md file documents most of this.

neat!

Is there a strong desire to have this file? Who is the audience?

A similar file has been created in the other APM Agents, this could help to anyone regardless of the APM agent team. Do you think this file could exist with a redirect to the TESTING.md?

I could easily do so if that would mean we could avoid this file

Great, that's a good plan

Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
## CI/CD

There are 5 main stages that run on GitHub actions:

* Linting
* Test
* TAV
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* TAV
* TAV, (knowing as Test-All-Versions)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* TAV
* Test-All-Versions (TAV)

* Release

There are some other stages that run for every push on the main branches:

* [Edge](./edge.yml)
* [Microbenchmark](./microbenchmark.yml)
* [Snapshoty](./snapshoty.yml)

### Scenarios

* Compatibility matrix runs on branches, tags and PRs basis.
* Tests should be triggered on branch, tag and PR basis.
* Commits that are only affecting the docs files should not trigger any test or similar stages that are not required.
* Automated release in the CI gets triggered when a tag release is created.
* **This is not the case yet**, but if Github secrets are required then Pull Requests from forked repositories won't run any build accessing those secrets. If needed, then create a feature branch.

### Compatibility matrix

Node.js agent supports compatibility to different Node.js versions and frameworks, those are defined in:

* TAV [frameworks](../../.ci/tav.json) for all the commits. **NOTE**: on PRs is a dynamic choice based on the changeset or the GitHub comment.
* Node.js [versions](https://github.com/elastic/apm-agent-nodejs/blob/d6db3bcb9c15f119f2b98cb04f2d4a4932118441/.github/workflows/test.yml#L128-L142) for all the `*nix` builds.

### How to interact with the CI?

#### On a PR basis

Once a PR has been opened then there are two different ways you can trigger builds in the CI:

1. Commit based
1. UI based, any Elasticians can force a build through the GitHub UI

#### Branches

Every time there is a merge to main or any release branches the whole workflow will compile and test every entry in the compatibility matrix for Linux.

### Release process

This process has been fully automated and it gets triggered when a tag release has been created.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it really fully automated? I think there are some manual steps needed before the tagging. E.g. #3613

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release is tag based driven, so as soon as the tag is created then it produces the bundles, publish and create the release. Probably I might need to change the words to say it tag release based and the release is automated once the tag is created.

Copy link
Member

@reakaleek reakaleek Sep 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that the publishing/deplyoing to NPM, elastic.docker.co and AWS is fully automated.

However, the whole Release Process starts with some changes like incrementing the version in package.json which is currently done through PRs before the commit is tagged.

The tag release follows the naming convention: `v.<major>.<minor>.<patch>`, where `<major>`, `<minor>` and `<patch>`.

### OpenTelemetry

There is a GitHub workflow in charge to populate what the workflow run in terms of jobs and steps. Those details can be seen in [here](https://ela.st/oblt-ci-cd-stats) (**NOTE**: only available for Elasticians).

## Bump automation

[updatecli](https://www.updatecli.io/) is the tool we use to automatically update the specs
the [APM agents](./updatecli.yml) use.