https://cloudposse.com logo
Join Slack
Powered by
<https://github.com/cloudposse/atmos/pull/1894> I ...
# atmos-dev
p
https://github.com/cloudposse/atmos/pull/1894 I can't believe I missed that when I created the original PR , now obviously I need it
👀 1
❤️ 1
e
This brings native CI integration into atmos so 
cloudposse/github-actions-atmos*
are not needed.
• status checks API
• PR commments
• Job summaries
• matrix generation
• 
GITHUB_OUTPUT
• pluggable, so adapters can be written for Gitlab/ADO/etc
p
ufff that is cool and tricky......
e
what do you see as tricky?
p
I use vendoring heavily, you will not believe how many problem I have with it, so for me debugging is super tricky
e
Will this make your life easier?
p
so whatever the native integration is I need to be able to debug and backoff on github call is MANDATORY
when you have 300 PRs a day, you can ddos github very easy
e
so whatever the native integration is I need to be able to debug and backoff on github call is MANDATORY
oh, that's interesting! So what if it could automatically handle retries with backoff?
what it it automatically understood the 429 backoff to retry
that would be easy to add to this
p
let me say it this way: if you do not have backoff, I can't use it
so yes , please add it
( you can look at atlantis on how we do some of this)
e
what are other gaps relative to atlantis?
• webhooks
• workflow hooks
• custom workflows
p
I will advice to stay away from adding to much stuff dealing with VCS APIs is a nightmare
to be honest I think atmos maybe should stay away from any CI workflow and whatever is added ( like vendoring) has strong support and features ( backoff etc )
also if you decide to go that route, state right away your intention, like 
We will not supports any VSC but github
etc
otherwise you will see a bunch of PRs to support gittea, AzureDevops , Gitlab, bitbucket etc and it will never end
e
I would say that's a sign of healthy adoption 😃
p
for atlantis it is, but it is very painful sometimes
but then I ask , is it for Atmos? what is the goal here?
( by the way I'm direct but I'm trying to be constructive here, I'm not bashing down ideas)
🙏 1
e
Understood - so like with auth, we'll probably only implement the methods we ourselves directly use; but also like with auth, we ❤️ the contributions from you and others.
the CI I see as a way for us to accept contributions for platforms we ourselves don't use, but provide a way for others to contribute. We'll continue to hold the standards high, and test coverage will have to be ~75%+ to be accepted.
i don't anticipate a flood of contributions right away
p
then I will say make it as pluggable libraries, so people can use them or not.
e
ya, a pluggable approach might be apt
p
I do not know if in golang you could create like a vendoring of plugins when they are enabled so that the main binary of atmos does not have the code for the VCS integration
e
it does follow a registry pattern, where each is isolated, but plugins not yet.
p
that way core stay super stable
2 Views
Open in Slack
PreviousNext
Powered by