docs: what the CI does #3599
docs: what the CI does #3599
Conversation
github-actions
bot
added
the
agent-nodejs
|
Please do NOT merge this yet. I have some feedback to give and we are trying to coordinate the "main" and "3.x" branches for a new 4.0.0 release soon. Thanks. |
.github/workflows/README.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
Could you please add some explanation what TAV means? Is it an abbreviation?
Co-authored-by: Jan Calanog <nejcalanog@gmail.com>
|
|
||
| * Linting | ||
| * Test | ||
| * TAV |
There was a problem hiding this comment.
| * TAV | |
| * TAV, (knowing as Test-All-Versions) |
There was a problem hiding this comment.
| * TAV | |
| * Test-All-Versions (TAV) |
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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
|
|
||
| ### Release process | ||
|
|
||
| This process has been fully automated and it gets triggered when a tag release has been created. |
There was a problem hiding this comment.
is it really fully automated? I think there are some manual steps needed before the tagging. E.g. #3613
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
A brief summary about some of the bits and pieces the CI/CD using GitHub actions do.
This will help us to move the centralised docs regarding the CI that we store in a private location.
Checklist