Closed onno-vos-dev closed 2 years ago
Pretty cool! Although I like the idea, I think we would be safer - from braking changes - if we only push when a new version of aws-sdk-go
is released.
I believe they release a new version everyday.
We could keep track of the last version of aws-sdk-go
we built in a file under both projects. WDYT?
Pretty cool! Although I like the idea, I think we would be safer - from braking changes - if we only push when a new version of
aws-sdk-go
is released. I believe they release a new version everyday. We could keep track of the last version ofaws-sdk-go
we built in a file under both projects. WDYT?
Sounds like a good idea! I'll try it out on my forks and will update accordingly :-) So sit tight for a few days :+1:
Managed to make the necessary change :-) Bonus is that the commit now includes the tag that was used to generate the code.
You can see the aws-elixir build here and aws-erlang build here
See: onno-vos-dev/aws-elixir/commit/423469314f6fd142 and onno-vos-dev/aws-erlang/commit/4ea8d5949449 for an example :-)
I'll let it run for a few days before updating this PR
@philss Updated now so it only builds if the tag has changed or if the tag remains the same (in which case aws-codegen
itself may have changed on a push to master and hence code should be regenerated as well.
You can see last nights crontab in action here for Elixir and here for Erlang. Resulting in the following commits for Elixir here and for Erlang here
@philss Sorry for letting this slide, I've been very busy the past few weeks. I'll tidy this up tonight :+1:
@onno-vos-dev no problem. Take your time :)
Sorry for the delay :blush: Life and a vacation got in the way.
Fixed the comments you had. It's been tested on my local fork of master
as can be seen here:
https://github.com/onno-vos-dev/aws-erlang/commits/master
https://github.com/onno-vos-dev/aws-elixir/commits/master
In theory, this should be ready to rock and roll :-) If you approve, I'll draft up the instructions as to how to setup the PERSONAL_ACCESS_TOKEN
that will be required in this repo in order to allow pushing to aws-elixir
and aws-erlang
Thanks @philss Since I'm not part of the aws-beam
organization I'm gonna need you or someone else to fix the PERSONAL_ACCESS_TOKEN
, I'll write up the necessary instructions tonight :+1:
@philss Again apologize for the delay but here are the instructions to set up the magic needed for this to work :+1:
Here are the instructions, if unclear, please let me know and I'll try and clarify or we can jump in a hangout and do it together whenever it suits you :+1:
Step 1: Go to developer settings on the aws-beam
settings and click generate new token
:
Step 2: Give the token a name. Any name will do but I chose PERSONAL_ACCESS_TOKEN :-) Select the settings as chosen in the screenshot. Scroll down and click Generate token
. Ideally an expiration time should be used but for my personal repo I chose No expiration
. It's fine to set a date, it's just that the token will have to be refreshed some time in the future otherwise. Ergo, these steps need somewhat repeating then :+1: No major drama either way but for security's sake it's probably best to set a token that expires.
Step 3: Copy the token as displayed on the screen.
Step 4: Go to the settings of aws-codegen
project and via secrets
click on New repository secret
.
Step 5: Add the name PERSONAL_ACCESS_TOKEN
(this must be exactly this as the workflow relies on that name). Add the copy pasted token there.
Again apologize for the delay but here are the instructions to set up the magic needed for this to work +1
No problem. Thanks!
I realized I don't have access to such settings. But for what I could understand, the default GITHUB_TOKEN
already have permissions for pull and push from/to repositories of the same organization.
I will try to use the default token, but please update the workflow file to point to this organization first.
@philss I can try to give you access if you are interested and it turns out that I can. π
Let me know!
Or to you @onno-vos-dev. π
Let me try with the default GITHUB_TOKEN. I have memories that it didn't work but it's still early enough in the day for my memory to sometimes deceive me π
Me memory was correct. I'm getting a 403 FORBIDDEN with GITHUB_TOKEN
at least :( https://github.com/onno-vos-dev/aws-codegen/runs/4918712079?check_suite_focus=true
Ok, thanks for trying @onno-vos-dev :)
@jfacorro can you give me access to the repo's settings?
@philss Done
@philss Any progress? :-)
@onno-vos-dev hey, sorry! :/
I was digesting the idea of using a personal token and I came to the conclusion that it's better not. Let me explain: the personal token is a way to let GitHub authorize a personal account to read/write to any repository on behalf of the user. This is OK if the thing in question is personal. But I think for open source, in a project that is managed by many, this can be insecure. If the token is leaked, my account will be compromised.
What I think can solve the issue is to have both workflows in the respective repositories (aws-elixir and aws-erlang). I will do that and add you as co-authored, OK?
Anyway, sorry for the delay.
@philss I understand your reasoning and totally see your point.
Go ahead and add them to their respective repos :-) If you'd like I can do it as well depending on if you have the time or not :+1:
@onno-vos-dev I'm tackling that, but I will accept reviews (probably tomorrow) :)
@onno-vos-dev thank you very much! :purple_heart: I'm closing this since the work was merged in the aws-elixir
and aws-erlang
.
This PR brings in two additional pipelines:
nightly-elixir
andnightly-erlang
which consequently will build and pushaws-elixir
andaws-erlang
both on push tomaster
as well as nightly at 00:23 server time.The idea here is that I think it's awesome to have auto-generated based on the official AWS SDK GO but it's even more awesome to do this every night and bring any bugfix, new library and other shiny stuff in on a nightly basis and roll out the code accordingly. If any fix is applied to the generator code, one should not have to generate the code yourself and then creating the subequent PR in the
aws-elixir
oraws-erlang
repo but this should happen automatically :smile:This PR by itself will not work as a personal access token has to be generated and put in place for this to work as the pipeline pushes cross-repos.
To test this, I've had this running in my forks for the last week or so and it's been working nicely :-)
You can see it in action here: scheduled jobs on fork With results in aws-elixir here: onno-vos-dev/aws-elixir/commits/master With results in aws-erlang here: onno-vos-dev/aws-erlang/commits/master
A few open questions:
master
or to some imaginarynightly
branch? In the latter, what should the process look like for mergingnightly
intomaster
?If you feel you'd like to move forward with this PR, I'm happy to try and assist in making sure that the personal_access_token stuff is setup accordingly :+1: