Closed fotos closed 8 months ago
@cortinico looking into the current releases I noticed they have been created by the react-native-community-bot
. My gut feeling tells me that I shouldn't have removed the GH_TOKEN
from the ENV because that most likely belonged to react-native-community-bot
and was used to push the releases back to GitHub. Although I think the GH_TOKEN
was already expired because the releases didn't happen anyway.
Do you have access to the react-native-community-bot
account? We might need a new token for semantic-release
.
@cortinico looking into the current releases I noticed they have been created by the
react-native-community-bot
. My gut feeling tells me that I shouldn't have removed theGH_TOKEN
from the ENV because that's most likely belonged toreact-native-community-bot
and was used to push the releases back to GitHub.Do you have access to the
react-native-community-bot
account? We might need a new token forsemantic-release
.
Yes, looks like the GH_TOKEN
is going to be required by semantic-release
in order to push the tags back. This is also mentioned in the CircleCI documentation.
When you add a new project, CircleCI creates a deployment key on GitHub for your project. A deploy key is an SSH key-pair, one public, one private. GitHub stores the public key, and CircleCI stores the private key. The deployment key gives CircleCI access to a single repository. To prevent CircleCI from pushing to your repository, this deployment key is read-only.
If you want to push to the repository from your builds, you will need a deployment key with write access. See the below section for GitHub-specific instructions to create a deployment key.
(emphasis mine)
Currently the react-native-community-bot
is acting as a machine.
I think we need to get access to the react-native-community-bot
account, create a new PAT scoped with appropriate permissions for this project and then add the token as the GH_TOKEN
environment variable. That should allow semantic-release
to push tags.
Currently the
react-native-community-bot
is acting as a machine.
Nope I don't have it.
How about we just don't use semantic-release for now to unblock the situation and then get back to setting it up in the future?
Currently the
react-native-community-bot
is acting as a machine.Nope I don't have it.
How about we just don't use semantic-release for now to unblock the situation and then get back to setting it up in the future?
Sure. We can merge this PR and tag a release manually via GitHub UI.
@cortinico this went better except the node/run
job which failed as expected.
Will you create a new tag in GH UI or shall I do that?
Will you create a new tag in GH UI or shall I do that?
Please go ahead π
Will you create a new tag in GH UI or shall I do that?
Please go ahead π
Just pushed the v7.4.0
tag. CI is running.
Truth be told I'd rather have figured out the GH_TOKEN
for semantic-release
. What we did is an ugly workaround and there is quite some clean up to sort things out (CHANGELOG, versioning, GH releases etc.).
How can we find the credentials for react-native-community-bot
?
Can I also get admin access to the project to sort out the CHANGELOG etc by running semantic-release
locally and (re)doing the GH releases/tags?
@cortinico everything went well except publishing didn't work because the CIRLCE_TOKEN
environment variable is missing. To be honest at this point I'd rather get admin access to the project and do things the right way (β’οΈ) than continue to blindly hack-around. What do you think?
My understanding of how this publishing is supposed to work:
orb-tools/publish
job requires a CIRCLE_TOKEN
environment variableorb-publishing
context (template)The documentation on orb-tools/publish
mentions:
Enter the name of the environment variable containing your CircleCI API Token. This token must have production publishing scope (organization owner). Never directly enter the value of any secret tokens in your config.
So, it looks like we need secrets from the organization owner anyway.
Truth be told I'd rather have figured out the
GH_TOKEN
forsemantic-release
. What we did is an ugly workaround and there is quite some clean up to sort things out (CHANGELOG, versioning, GH releases etc.).
Can't we just use the GitHub Actions Token to run semantic-release?
Can I also get admin access to the project to sort out the CHANGELOG etc by running semantic-release locally and (re)doing the GH releases/tags?
You should have access now π
Truth be told I'd rather have figured out the
GH_TOKEN
forsemantic-release
. What we did is an ugly workaround and there is quite some clean up to sort things out (CHANGELOG, versioning, GH releases etc.).Can't we just use the GitHub Actions Token to run semantic-release?
I'll look into that now.
Can I also get admin access to the project to sort out the CHANGELOG etc by running semantic-release locally and (re)doing the GH releases/tags?
You should have access now π
Thank you β let me see what I can do.
By the way I'll gladly relinquish admin access as soon as we get the CI/CD working again.
@cortinico I spent invested 2 hours and this is where we stand:
I went through all the scripts in orb-tools
to understand how an orb version is published. It boils down to two circleci
commands. For example to publish version 7.2.0
:
$ git checkout v7.2.0
$ circleci orb pack src > dist/orb.yml
$ circleci orb publish dist/orb.yml react-native-community/react-native@7.2.0
To do the above requires a CIRCLE_TOKEN
. What is the CIRCLE_TOKEN
and how is it created? When following the guide at the circleci orb init
step, the setup process generates a CircleCI personal token and stores it in the orb-publishing
context as the CIRCLE_TOKEN
environment variable. This is described clearly in the guide:
In the setup process you will be asked if you would like to save your personal API Token into an orb-publishing context. Saving this token is necessary for publishing development and production versions of your orb.
I manually created a token from my (CircleCI) account. Then I created the orb-publishing
context and added the token there. Ideally this token shouldn't be from my account but instead it should be from the react-native-community-bot
machine user.
In any case, unfortunately my account doesn't have sufficient access to publish orbs:
$ circleci orb publish dist/orb.yml react-native-community/react-native@7.2.0
Once an orb is created it cannot be deleted. Orbs are semver compliant, and each published version is immutable. Publicly
released orbs are potential dependencies for other projects.
Therefore, allowing orb deletion would make users susceptible to unexpected loss of functionality.
Error: User does not have access to publish SemVer orbs in this namespace.
I found out that in order to publish an orb
the CircleCI account must have organization level permissions:
Orb CLI commands are scoped to different user permission levels, set by your VCS. You are the owner of your own organization. If you are authoring or publishing orbs for a namespace owned by another organization, you may require assistance from your organization admin
That means, if I can have organization level permissions I will be able to publish the 2 missing orb versions easily.
Alternatively we need a token from an "owner". I'm pretty sure that react-native-community-orb
is listed as an organization owner for exactly this reason. I considering this the best way forward.
Similarly for semantic-release
, a GH_TOKEN
is required. That personal access token (PAT) should belong to a user who has admin
access to the repository and can create PATs scoped to the organization. Again, I'm pretty sure the react-native-community-bot
is such a user. The bot is certainly an admin on the repository:
If we login as the bot we can create a fine-grained PAT with the necessary permissions to push tags:
The generated token can be stored as an environment variable as GH_TOKEN
or added to the orb-publishing
context (and the node/run
job changed to use the orb-publishing
context).
react-native-community-bot
or a user who is organization owner and admin at the repository.orb-publishing
as CIRCLE_TOKEN
. We can use that token to publish the missing versions (v7.2.0
and v.7.3.0
) easily using the command posted above.semantic-release
.It's better (more secure) to use the react-native-community-bot
user because it is (implicitly) scoped to the react-native-community
org. If I use a personal CircleCI token (e.g. mine or yours) and we are also members of other organizations (we are), and the token leaks it can be used across orgs β that's a bad idea.
In short⦠I believe if I can get access to the react-native-community-bot
account I'll be able to do all the above: publish missing orbs, fix the CI/CD for publishing the orb going forward, and configure the pipeline for doing semantic release automatically (and perhaps restore order to the galaxy).
Got any ideas how we can access the bot account? Ask Matt? Other members of the community?
Alternatively we need a token from an "owner". I'm pretty sure that
react-native-community-orb
is listed as an organization owner for exactly this reason. I considering this the best way forward.
We don't have access to it. I guess the best would be to create a new bot account (react-native-circleci-orb-bot
) and reach out to CircleCI to move the ownership
Alternatively we need a token from an "owner". I'm pretty sure that
react-native-community-orb
is listed as an organization owner for exactly this reason. I considering this the best way forward.We don't have access to it. I guess the best would be to create a new bot account (
react-native-circleci-orb-bot
) and reach out to CircleCI to move the ownership
Cool β no worries. I'll create a new machine user now and we can add to the org and the project. That's also a very reasonable approach if we don't have access to react-native-community-orb
. On it.
@cortinico I created react-native-circleci-orb-bot
. I'll create the necessary GH PAT and add the bot as an admin to the project. Can you add the bot as an org owner too so it can publish orbs?
and reach out to CircleCI to move the ownership
I don't believe we need to reach out to CircleCI to move the ownership. CircleCI is assigning ownership based on the GH permissions. If the new react-native-circleci-orb-bot
is made a react-native-community
organization owner then it will be able to publish the orb in CircleCI. That's my current understanding and expectation.
Anyway the new bot is ready. I'll wait for the org ownership and then I'll proceed with the steps I listed above.
I'll be around all day today. π
Anyway the new bot is ready. I'll wait for the org ownership and then I'll proceed with the steps I listed above.
Yup I've sent an invite to the bot. Could you also share the bot credentials with me (my contacts are available on my GH profile)?
Anyway the new bot is ready. I'll wait for the org ownership and then I'll proceed with the steps I listed above.
Yup I've sent an invite to the bot. Could you also share the bot credentials with me (my contacts are available on my GH profile)?
Accepted the invite. Sent you the credentials. β
@cortinico OK, the CIRCLE_TOKEN
from react-native-circleci-orb-bot
worked. I just published the pending versions and closed the other issue. The token is added in the orb-publishing
context and the context is restricted to this repository.
Now I'll figure out the GH_TOKEN
for semantic-release
and might merge a (simple) PR, like the dependabot ones, to trigger the CI/CD pipeline.
@cortinico the GH_TOKEN
is also in place. I haven't tried doing a release but I expect that the next feat
or fix
merge will automatically trigger a new release. If not let me know and I can take another look. PRs / commits need to follow conventional commits.
My part here is done for now. π
My part here is done for now. π
Amazing work @fotos Thanks for unblocking this situation!
:tada: This PR is included in version 7.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Move the
release
step under thetest-deploy
workflow.Previously the (setup) workflow failed with:
Turns out dynamic configurations that use
setup: true
can have only one workflow defined.Now the idea for the flow is:
After the tag is pushed to
GitHub
this triggers another CI run with:(My π§ββοΈ diagramming sucks but hopefully you get the idea)
This PR is a follow up to #177.