-
Notifications
You must be signed in to change notification settings - Fork 230
ci: run the release when merges to main #1998
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.
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @v1v !
@xrmx , I might need your help with this approach:
Then, a second run failed: https://github.com/elastic/apm-agent-python/actions/runs/8229823579/job/22501787751 What do you suggest? |
@v1v can we postfix a |
Nice, but I have no clue how to do it; I can try to figure out but if you know how to, would you mind contributing to this PR? 🙏 |
Sure, will take a look later today |
@v1v What do you think about somethings like this
and then exposing to the packages workflow an ELASTIC_CI_LOCAL_VERSION environment variable with the value of |
@xrmx, quick question:
if Rationale: I want to use a top-level environment variable, with something like:
Then I need to find how to use the ternary in GitHub actions |
Empty string is fine, code checks for a truthy value and empty string is not. Unless you are sending the single quotes |
no single quotes, but empty instead, single quotes will be empty in this particular case, I think that's the way to set empty env variables |
env propagation between reusable workflow is not supported
Make it possible to add a post version (per PEP-440) to the current agent version at build time. This will be useful because we want to continuously build the agent on CI and avoid version conflicts when publishing to test pypi. So when returning the agent version add anything that has been passed in ELASTIC_CI_POST_VERSION environment variable as post version. Refs elastic#1994
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
* ci: run the release when merges to main * avoid wrong docker-tag name * use the opposite * fix yaml * enable test, slack message conditional and fix names * Update .github/workflows/release.yml * skip test for branches in the release workflow * workaround * fix * Update .github/workflows/release.yml * support releases in test.pypi for commits on main * set environment variable in the reusable workflow instead env propagation between reusable workflow is not supported * setup: take a post version from environment variable * Update .github/workflows/release.yml --------- Co-authored-by: Riccardo Magliocchetti <[email protected]>
What does this pull request do?
Use https://test.pypi.org/ to test the Release GitHub workflow on
main
and skip push changes. If a release tag then it behaves as usual, publishing the release.Related issues
Closes #1994
Implementation details
It skips anything related to pushing the docker images, lambda functions or GitHub releases.
Potentially we could use a different AWS account or docker registry, though those steps are only about pushing the changes. If needed we can do a follow-up.
Test
I created a feature branch called
test/release
based on this PR, and the build is now running, see hereIt failed with